[08:46] mornin' [09:16] hi rog [11:13] Hello all! [11:14] Hello. [11:20] niemeyer: welcome home! [11:24] rog: Thanks! :) [11:27] niemeyer: welcome back [11:27] TheMue: Thanks! [11:49] rog: lbox seems to be working well [11:49] rog: You're right about pre-req.. the diff should come from the pre-req branch [11:49] rog: Will address this later [11:50] niemeyer: it's difficult though, because the prereq branch is a moving target. as is the target itself, i guess [11:50] rog: Yeah, that's probably not a big deal [11:50] niemeyer: it's a pity the target has to be on disk. [11:51] niemeyer: i've made a shell script that does quite a lot of the stuff i always need to do; i don't know how much would be generally applicable though. [11:51] rog: The main concern I have is that it feels easy to merge a branch without addressing the pre-req first, and as a consequence merging the pre-req without reviewing it [11:51] rog: I was going to address that in your email, but we can talk here as well [11:51] http://paste.ubuntu.com/752390/ [11:51] rog: It's actually not a pity [11:51] rog: This is standard distributed revision controlling [11:52] i just fetch the target every time now [11:52] into /tmp or somewhere [11:52] rog: You're used to the Go process, but their process is well sub-standard in that regard [11:52] rog: This feels quite bad [11:52] yeah, but it stopped me making the same mistake every time [11:53] rog: The usual way to develop software with any of the DVCS tools (bzr, git, hg, ..) [11:53] niemeyer: which was that i'd specify, say, ../go-trunk as a target, but i might have a different push target inside go-trunk [11:53] rog: is to fetch the pristine code locally, and work with branches on top of it [11:54] rog: Hmmm.. how do you mean? [11:54] rog: There's only one go-trunk? [11:55] i think i'd probably done: cd go-trunk; make-some-changes; push --remember lp:~rogpeppe/blah/foo [11:55] rog: Yeah, that's the issue [11:55] which was probably a silly thing to do, but it caught me out twiece [11:55] s/twie/twi [11:55] rog: yeah, don't do it.. you may end up even screwing up the real trunk by mistake [11:55] rog: branch locally [11:56] the other thing is when i want to edit some code that i've goinstalled [11:56] i want to do: cd $GOROOT/src/pkg/launchpad.net/goamz/ec2; edit; commit; propose [11:57] rog: We covered that at UDS [11:57] rog: Don't edit the pristine version [11:57] rog: Work in a real branch [11:59] yeah, it's just much easier to get things wrong in that situation, because i'll be using two packages pushing to the same location in GOROOT [11:59] and i have to remember where i put the darn branch [12:00] rog: Not really, that's the idea [12:00] also (and a different issue i think), i can't specify $GOROOT/src/pkg/launchpad.net/goamz/ec2 as a target [12:00] rog: Use different GOPATHs [12:01] i can't use GOPATH because gotest doesn't work [12:01] i'm still biting my lip on that one [12:01] i really want to use GOPATH! [12:01] rog: The two things are unrelated [12:01] rog: Sorry, let me rephrase that [12:01] rog: You don't have to keep your source code at $GOROOT [12:01] rog: That's the real point [12:02] rog: You can have as many branches as you want installing onto GOROOT, or even a different GOPATH for that matter [12:02] niemeyer: i think i do if i want to be able to use gotest on the source code [12:02] niemeyer: unless it's been fixed recently [12:02] rog: I use that scheme, and I use gotest [12:02] rog: Nope, no recent changes to that [12:03] rog: make install always installs to $GOROOT [12:03] niemeyer: hmm, so if i've got GOPATH set and i go into a source directory in GOPATH and gotest, it works? [12:03] rog: gotest doesn't use GOPATH.. you can use gotest locally irrespective of where your source lives [12:04] but i also like to be able to use goinstall [12:05] rog: Yeah, I like ponies too :) [12:05] because it means that when i upgrade Go, i don't have to manually go through running make on every package i might have forked [12:05] goinstall -a is really useful [12:05] (and has saved me lots of time) [12:07] anyway, my current scheme works ok - i keep directory $HOME/tmp/targets with a set of pristine targets, then before proposing, i update the target and use that [12:08] that means that i don't have to worry about whether i might have accidentally locally corrupted a target [12:12] niemeyer: here's an idea: in the file with the summary & description that's edited as part of the propose process, why not put a summary of all the details that propose has inferred? [12:12] then it's more obvious when you've got the wrong push target, missed the prereq, etc [12:13] rog: We can do that, but it doesn't solve the main problem, which is the danger of merging a branch that has a pre-req without addressing the pre-req first [12:13] rog: We can probably create some convention to avoid the problem.. I'll think about it some more [12:17] rog: I'll also tweak lbox to not force the description [12:18] rog: it would also be nice if you didn't have to give the target when re-running lbox propose. maybe "lbox update" would be a more appropriate name. [12:22] rog: The name is fine (you're still proposing), and in the setup I suggested you don't actually have to provide a target at all [12:22] rog: Because it's the parent branch [12:22] niemeyer: hmm. what it's not the parent branch? [12:22] rog: Sorry, I don't get the question [12:23] niemeyer: what if you're not pushing to the parent branch? [12:23] niemeyer: that is, if you've branched from another local branch, but want to use the original parent as target? [12:24] niemeyer: or perhaps i've misunderstood [12:24] rog: I see [12:24] rog: No, you got it [12:25] rog: Hmm.. this might help solve both issues perhaps.. [12:26] rog: I'm wondering how the workflow would look like if it _was_ the actual target [12:26] niemeyer: if what was the target? [12:26] the prereq? [12:26] rog: The awkwardness is that it'd prevent the base from being merged [12:26] rog: Right [12:27] rog: Since we'd want to merge the follow up on it [12:27] Probably a bad idea [12:27] yeah, it doesn't sound quite right [12:28] the other issue i came up against is that you can't have two prereqs [12:31] rog: Indeed, I've missed that before too [12:31] rog: That said, at some point it's easier to just hold off the branch a bit [12:31] rog: Even for everyone's sanity [12:33] niemeyer: maybe i should have just done that, and push each branch when you've LGTM'd the previous one [12:34] BTW when i did lbox propose to upload a change to goyaml-error-fixes, i got this: http://paste.ubuntu.com/752421/ [12:34] i wonder why it didn't find the previous merge proposal [12:34] rog: This would work, but it's a nice feature to be able to push dependent branches.. [12:35] rog: Maybe we can, by convention, not LGTM a branch that has pre-reqs before the pre-reqs themselves have been sorted [12:35] rog: This would solve the worries [12:35] niemeyer: a related possibility is to use an lbox command to do the final push [12:36] niemeyer: and that could check that the prereq had been pushed before doing it [12:36] rog: It found the branch itself as the landing target [12:36] rog: Can you please paste "bzr info" there? [12:36] yeah, i just worked that out [12:37] i know why it happened [12:37] rog: It sounds like your custom workflow is getting in the way there [12:37] it's because i'd deleted my local copy of the branch [12:37] thinking i could always re-get it from lp later [12:37] but by getting it again, i lost the original parent [12:38] http://paste.ubuntu.com/752425/ [12:38] rog: Yeah, that's it [12:38] Cool [12:38] niemeyer: i don't think it was because of my custom workflow [12:39] rog: It was.. [12:39] niemeyer: because deleting a local copy of the branch isn't customary? [12:39] rog: In traditional DVCS workflows you don't really kill the local branch while you're working on it [12:40] niemeyer: i actually didn't delete it - i carried on editing and committing towards a later merge request [12:40] it's because i'd deleted my local copy of the branch [12:40] thinking i could always re-get it from lp later [12:40] ?? [12:40] niemeyer: well, in my head it was deleted... [12:41] rog: In Bazaar's head too, apparently, since you got the branch again from Launchpad (the parent says so) [12:41] niemeyer: it had turned into a new branch, which i didn't want to interfere with [12:41] niemeyer: maybe there was another way i could have got it from launchpad so that the original parent was preserved [12:41] niemeyer: i didn't know that parentage was so important [12:41] rog: Just don't kill the branch while you're working on it [12:42] rog: The branch existence is important [12:42] niemeyer: yeah, i should just re-branch every time i do a merge request [12:42] niemeyer: rather than carrying on working in the same directory [12:42] rog: Yeah, every time you want to start a new line of development, re-branch [12:42] niemeyer: it's a bit of a pain because i have to lose all my editing state. [12:43] rog: FWIW, that's a normal impedance mismatch when getting into DVCS [12:43] rog: That bit of it is due to Bazaar's way of working with multiple directories [12:43] rog: This is going to be addressed soon [12:43] rog: With a git-like workflow, you can have multiple branches in the same directory [12:43] niemeyer: of course. other VCSs you'd still be in the same dir [12:44] rog: bzr is getting the same feature [12:44] niemeyer: i think you *can* do that now - someone pointed me at a way of doing it [12:44] niemeyer: but it's probably a hack [12:44] rog: http://doc.bazaar.canonical.com/developers/colocated-branches.html [12:47] niemeyer: anyway, regardless of glitches, it's awesome that we've got proper code review working! nice one. [12:47] rog: Totally, I'm very happy about that [12:49] niemeyer: one thing: i think lbox propose should complain if there are uncommitted changes. i often forget to commit! [12:49] niemeyer: (just like bzr push complains) [12:50] rog: Agreed [12:51] rog: I was already planning something like that.. will tweak the Delta interface on goetveld [12:52] niemeyer: BTW, i tried pushing to lp:goyaml and got "Transport operation not possible: readonly transport". is that because i'm not yet recognised as a member? [12:52] niemeyer: or do i have to re-branch, now that i am? [12:52] rog: No, just because of the URL [12:53] niemeyer: is it the wrong url? [12:53] rog: If you look at bzr info, you'll see the URL is a read-only one [12:53] rog: You can push explicitly to lp:~gophers/goyaml/trunk [12:54] where in the info (http://paste.ubuntu.com/752435/) does it say read-only? [12:54] ah, you mean the url for lp:goyaml? [12:54] so is lp:~gophers/goyaml/trunk an alias for lp:goyaml ? [12:55] niemeyer: or is there something else subtle going on here? [12:55] rog: It is now, but it wasn't at the time you branched [12:55] rog: Oh, hold on [12:55] rog: It's my fault, actually [12:56] rog: I've changed the project maintainer, but not the branch [12:56] rog: It's still pointing to my personal branch [12:56] niemeyer: ah, so bzr push lp:goyaml should work, in fact? [12:56] rog: So, let's do this.. push it to the ~gophers URL.. I'll tweak the official branch location after that [12:56] rog: It will, definitely [12:56] cool [12:57] niemeyer: pushed now [12:57] rog: Done, we have a new lp:goyaml [12:58] niemeyer: cool. [12:59] rog: You're right, btw, we need an "lbox merge" [13:00] fwereade: Hey! [13:00] heya niemeyer! [13:00] rog: Or "lbox submit" perhaps.. :) [13:00] good holiday? [13:00] fwereade: Yeah, awesome [13:00] niemeyer, cool, where did you go? [13:00] fwereade: afternoon guvnor [13:00] heya rog [13:01] fwereade: I went to João Pessoa, a very nice region in the northeast of Brazil [13:01] g'morning [13:01] fwereade: I went to João Pessoa, a very nice region in the northeast of Brazil [13:01] hazmat: morning! [13:01] heya hazmat :) [13:01] niemeyer, welcome back, sounds like a nice vacation [13:01] hazmat: Thanks! Yeah, it was very relaxing [13:02] Left the laptop at home for a change [13:03] niemeyer, ah a disconnected holiday, even better.. pics of those clear blue seas from pessoa look amazing [13:03] hazmat: Not entirely disconnected.. still had a phone with me.. but at least severely restricted, let's say ;) [13:04] hazmat: Yeah, in the last day we went snorkeling here: http://perlbal.hi-pi.com/blog-images/536061/gd/1264122522/Picaozinho-Joao-Pessoa.jpg [13:05] niemeyer: another occasion it didn't seem to find the original merge proposal: http://paste.ubuntu.com/752444/ [13:05] It's about 1km from the coast inwards [13:05] niemeyer: looks lovely [13:05] rog: yeah, now the problem is a different one [13:05] rog: The merge proposal is off since we renamed the branch [13:06] niemeyer: ah, because lp:goyaml is just an alias, right? [13:06] rog: That's right.. the merge proposal is still against lp:~niemeyer/... [13:06] rog: You can let it know by hand of the target, and it will work [13:06] niemeyer: that would be better than making a new proposal? [13:07] rog: I guess.. it'd avoid having you jump back and forth removing the previous one in lp and cr [13:07] niemeyer: we might have implemented lbox submit... which would submit to the wrong place :-) [13:08] rog: Indeed.. luckily we won't be renaming things like that very often [13:08] true [13:08] niemeyer: so the original target was lp:~niemeyer/goyaml/goyaml ? [13:09] /trunk at the end [13:09] ah, of course [13:11] niemeyer: ok, i did the propose, but the codereview diffs seem unchanged [13:12] niemeyer: https://codereview.appspot.com/5432068/ [13:12] ahhh f*!# [13:12] * niemeyer waits for the bomb [13:12] niemeyer: i have to change the target... of course! [13:12] rog: Ah, indeed :-) [13:13] niemeyer: otherwise i don't see the diffs against the target i've just pushed to [13:13] doh! [13:16] niemeyer: that's better: https://codereview.appspot.com/5431087/ [13:16] rog: WOohay! [13:18] rog: Done [13:20] niemeyer: "branches have diverged". dammit! [13:23] rog: I don't know what your doing, but the way this generally works is that we all have a local copy of trunk.. [13:23] rog: Before merging a branch, pull from the remote to get the latest changes, [13:23] rog: Then merge and push [13:24] niemeyer: yes, that was silly - i forgot the merge step. [13:25] niemeyer: i thought the problem was because the trunk had changed name [13:26] niemeyer: submitted [13:34] Is there anyway to catch if a relation has been broken? [13:41] hi all [13:42] marcoceppi: Can't you do that with juju status? [13:42] Is there a specific documentation i should look at for running juju in my existing openstack infrastructre? [13:44] the documentation i am looking at is https://juju.ubuntu.com/docs/getting-started.html [13:44] marcoceppi: You mean within a charm? [13:44] niemeyer: Yes [13:45] marcoceppi: Yeah, there's both relation-departed and relation-broken [13:45] marcoceppi: https://juju.ubuntu.com/docs/charm.html#hooks [13:45] marcoceppi: departed is likely what you want [14:10] how do we pass initialisation options to zookeeper? [14:13] looking in juju/providers/common/cloudinit.py, i can see how zookeeper gets run (zookeeperd package, thanks hazmat), but i can't see how we configure the zookeeper adress, for example. [14:13] fwereade: ^ [14:13] rog, the zk address is the default address port 2181 on all ifaces [14:14] rog, hazmat beat me to it :) [14:14] hazmat: so the answer is "we don't"? [14:14] rog, its pretty common for daemons to bind to all available interfaces on their standard port [14:14] rog, yup [14:14] hazmat: ok, that makes more sense now [14:15] hazmat, fwereade: i couldn't work out how ZOOKEEPER_ADDRESS was getting through, one way or the other. there's so much care taken to make it configurable... [14:17] rog, ZOOKEEPER_ADDRESS is different.. its used to pass the ip:port info to agents, its passed on as an env variable to the agent process [14:17] its not used to configure zookeeper but the things using zookeeper [14:17] * rog nods [14:21] marcoceppi, -departed is called when any unit of the related service is removed, -broken is called when the relation is removed [14:21] koolhead11, the ec2 provider is used for openstack, there's an example in the list and on askubuntu [14:23] hazmat: i googled and found one such thread started by jcastro [14:23] but no much info. [14:23] hazmat: juju/control/initialize.py was the confusing bit. ZOOKEEPER_ADDRESS will never be set there, right? [14:23] * koolhead11 goes back to askubuntu [14:27] hazmat, fwereade: or is there another subtlety i'm missing? [14:28] rog, sorry, let me check what's going on there [14:28] if it happens to be set it will be used [14:28] but: [14:28] zk_address = os.environ.get("ZOOKEEPER_ADDRESS", "127.0.0.1:2181") [14:29] does that answer your question? [14:34] rog: ^^ [14:35] fwereade: yes, i saw the default. i just wondered if there was ever an occasion when the default would not be used [14:35] fwereade: and i *think* the answer is never. [14:35] rog, offhand, I think so too [14:36] fwereade: good. i'm not too far off base then. [14:40] rog, the default is not used lots [14:40] rog, the common way the value is passed is via an environment variable [14:40] well at least for non bootstrap nodes [14:40] oh.. sorry [14:41] hazmat: that was my point - this *is* the bootstrap code [14:41] And that's lunch time.. [14:41] rog, indeed its always the default there [14:41] hazmat: cool. a comment (or even removing the env var reference) might help naive folks like me to understand things, i guess. [14:49] hazmat: So I've got a service that requires mysql. I want to capture when that interface goes away. So -broken if I were to remove the relations? Also, what information is passed to the hook? [14:52] marcoceppi, not much, the standard hook information + rel info (JUJU_RELATION), but afaicr its not possible to interrogate any of the remote settings via the hook cli api, because their already gone, the unit can interrogate its own settings though [15:02] I just need to find the hostname of the hook that broke off, is that still available in: relation-get private-address [15:11] marcoceppi, bruno had ftp ready for review didn't he? [15:14] jcastro: Not that I'm aware of, last I heard he was starting on it but I've been in and out all weekend [15:14] he was ready for review as he was asking me how to tag it, but I can't find his branch. :-/ [15:15] Neither can I :\ [15:27] marcoceppi, its not [15:27] marcoceppi, there could be a dozen remote hosts [15:28] depending on the type of relation and which endpoint it is [15:28] hazmat, do you have irc topic powers here? [15:28] jcastro, i do [15:29] hazmat: So I'm creating a phpMyAdmin charm and it's able to join to multiple mysql servers [15:29] I'd like to capture when one goes away and remove it from the cfg [15:30] jcastro, something in particular you'd like in it? [15:31] marcoceppi, are they separate relations or a single relation? [15:31] hazmat, office hours please, something like: Office Hours (1600-1900UTC) [15:31] just tacked on at the end or whatever === hazmat changed the topic of #juju to: http://j.mp/juju-florence http://j.mp/juju-docs http://afgen.com/juju.html http://j.mp/irclog Office Hours (1600-1900UTC) [15:33] Well, that's what I'm a little baffled about. Can you spin up multiples of the same service. Like have two separate MySQL services running independently of eachother within the same bootstrap? Or would you simple add-unit [15:44] marcoceppi, you can have multiple mysql services in an environment, and if you do add-unit you'd be adding units to the existing service, something like mysql doesn't really support multiple units of the same service outside of a master slave setup, which i believe the charm models as two separate mysql services with a master/slave relation, and in that case you can add-unit for slaves [15:48] * hazmat grabs lunch [16:04] it's ironic that the actual observed time to failure for my UPS was less (which happened sometime last night) than actually seeing a power failure. in fact no power failures here in the 7 years i lived here [16:08] jimbaker: at least when your UPS fails you've still got mains power... [16:13] rog, indeed, i do have amazingly reliable and inexpensive power here. time to build a data center in the basement ;) [16:13] speaking of which, there was an article i saw recently about using data centers to heat buildings [16:14] in cloudinit.py, add_ssh_key states that at least one ssh key is required. why is that? wouldn't it be ok in theory to have a juju machine that wouldn't accept any incoming connections? [16:14] jimbaker: i've heard that [16:14] jimbaker: mind you, i'm not sure i'd situate a data centre next to peoples' house - they have a nasty habit of burning down. [16:14] s/house/houses/ [16:14] data furnaces - http://www.nytimes.com/2011/11/27/business/data-furnaces-could-bring-heat-to-homes.html [16:15] jimbaker: not gonna be very good in summer though... [16:16] apparently as long as the ambient air temp is < 95 deg F, it should work for the servers, just venting heat outside at that time, instead of inside [16:16] with maybe the exception of one or two days a summer, that would be the case for my house [16:19] jimbaker: it's a nice idea. i wonder how data protection laws would apply to the home owner... [16:19] jimbaker: do you know the answer to the above question, BTW? [16:20] jimbaker: i'm just wondering what would break if we allowed no ssh keys [16:20] hazmat? [16:20] rog, i don't know the answer to cloudinit above. maybe just fix cloudinit for this case? [16:20] worth taking a look at its codebase [16:21] i'm not sure that cloudinit itself requires any ssh keys [16:21] but i may be mistaken [16:21] * rog goes to check [16:21] interesting related point about txaws not verifying ssl. didn't know this. sounds like another reason to move to boto, which does have such support [16:21] boto? [16:22] it's pretty much the standard library for working with aws [16:23] jimbaker: well, i'm using goamz :-) [16:23] jimbaker: when you say "not verifying" do you mean it doesn't check the cert chain? [16:23] rog, unlike txaws, it has extensive support for nearly all of the aws api. its disadvantages are that it is blocking (but easy to workaround with deferToThread, just like what we do elsewhere in the python version of juju) [16:23] rog, that's what i understand from niemeyer' [16:24] s email [16:24] jimbaker: Have you checked if boto is testing for SSL certs? [16:24] rog, the client needs ssh to work to connect the bootstrap node [16:25] jimbaker: Also, it's not an easy transition [16:25] niemeyer, this is based on http://www.heikkitoivonen.net/blog/2009/10/12/using-m2crypto-with-boto-secure-access-to-amazon-web-services/ [16:25] hazmat: so the bootstrap node needs to allow ssh. what about the other nodes? [16:26] rog, they need it minimally to support ssh/scp/debug-hook commands [16:26] hazmat: ok, so nothing crucial relies on it. just wanted to check. [16:26] jimbaker: If you actually read the code there, you'll notice that it's not boto that is verifying the certificate [16:27] jimbaker: If you're going to fix it for boto, you can as well fix it for txaws [16:27] rog, nothing internally no, except for client access to the bootstrap node [16:29] niemeyer, likely it's worth looking at both. again you raised a good point about txaws. at this point, i know that people use boto successfully in this way to verify ssl :) [16:29] hazmat: cool. so "You have to set at least one SSH key." should really be "The bootstrap node requires at least one SSH key. Without at least one SSH key, other nodes will not allow ssh access, e.g. ssh,scp, debug-hook" or something like that? [16:29] txaws has some users, but boto is used extensively [16:29] including with twisted as i understand it [16:30] rog, those other subcommands are part of the interface juju exports [16:31] jimbaker, boto is used by twisted? [16:31] er. with [16:32] hazmat: that's true, but they're not key to the infrastructure. i could imagine creating a high-security node that allowed no ingress. it wouldn't break anything to do that. thus "must" seems a bit strong. [16:32] hazmat: but YMMV of course [16:32] hazmat, i have seen boto + twisted in the openstack tests, for example [16:32] rog, by that notion ssh keys wouldn't be required at all post a REST interface [16:33] jimbaker, openstack doesn't use twisted anymore.. and its honestly its not a great example of proper usage of anything imo [16:33] hazmat: well, i guess REST implies some encryption 'cos we'd be using https, so yes, i'd agree. [16:33] its getting better, but the codebase was originally a ball of mud with different styles and mix of sync/async and library usage [16:33] hazmat, this was just in the tests. i know they are using gevent. probably want to find better examples before we decide anything :) [16:34] eventlet .. same difference though [16:34] jimbaker, there are no twisted imports in nova [16:35] hazmat: i certainly think we should default to allowing ssh access, but i'm not sure it should be strictly required. and in fact, i don't see anything that checks the requirement now - it'll probably just work as is [16:36] jimbaker, which tests?.. i don't know that we'll find many examples of twisted code bases using boto [16:37] hazmat, i will try to dig this up [16:37] jimbaker, to throw some counter points 1) boto code base is relatively bad, and barely has any tests 2) most of the coverage of AWS API is useless to juju [16:37] therve, this is in fact a very good counterpoint [16:38] the only thing we can say about boto is that it's heavily used across various impls of the EC2 api. whether or not that makes up, i don't know [16:38] the best thing would be extensive usage in the wild + extensive unit testing [16:39] anyway, just bringing up as a possibility [16:40] jimbaker, in the mean time, I'd be happy to help if there are problems with txaws :) [16:40] jimbaker, i think i missed the context here, we're just talking about ssl cert checking [16:40] hazmat: no, it is checked. [16:41] i believe this in ref to https://bugs.launchpad.net/txaws/+bug/781949 [16:41] <_mup_> Bug #781949: Must check certificates for validity < https://launchpad.net/bugs/781949 > [16:41] which was filed by niemeyer [16:41] I'll assign that to me [16:42] therve, thanks [16:42] jimbaker, we have to be careful there, or at least only do it optionally, openstack setups don't nesc have valid certs [16:43] jimbaker: Time machine.. [16:43] hazmat, sounds good [16:43] niemeyer, what do you mean? [16:44] which was filed by niemeyer [16:44] ... back in May. [16:45] niemeyer, yes, so that's good right? i'm just pointing this out to ensure it's the right bug in question [16:45] jimbaker: Yeah, I'm not saying it's bad in any way.. it was a just a bad joke [16:46] niemeyer, cool [17:02] hazmat, standup today? [17:10] we don't verify the amazon cert right now? [17:12] SpamapS, as i understand it, yes [17:12] thats quite serious IMO [17:12] theft of AWS credentials could be *VERY* costly [17:12] SpamapS, indeed. think of the possible botnets [17:13] just thinking of the possible bill [17:20] So, could I simply symlink upgrade-charm hook to the install hook? [17:24] marcoceppi: don't see why not... as long as you change idempotency guards to handle any re-install logic needed [17:24] m_3: Right, I just realized my install hook is idempotent and since the upgrade never runs the install again it would pretty much be exactly what the install does with the exception of a few things [17:25] marcoceppi: might have to add a couple of things like an initial "apt-get update" that you wouldn't normally need [17:25] Good point [17:30] marcoceppi: lp:charm/ceph is an example of this [17:31] w/o the additional apt-get update :) [17:35] Cool I think this charm is about ready. Need to test it a bit more [17:35] jcastro, this askubuntu thing is great ;-) [17:36] hmm.. i'm not sure if the unzip will respect symlinks or not [17:39] marcoceppi: awesome man! [17:40] koolhead17, you mentioned on askubuntu that you where able to bootstrap without a local ssh key.. afaik this isn't possible [17:40] ie. it should always error out if that's the case [17:41] hazmat: am trying to run juju on my existing openstack infra [17:41] * hazmat nods [17:41] juju bootstrap gave no error [17:41] it was juju status which failed [17:41] with some ssh related error [17:41] hmm.. that's a regression [17:41] and i can see an instance running too [17:41] juju-default [17:42]