[01:32] axw: standup? [01:33] oops [01:33] wallyworld: brt [02:41] wallyworld: doc/hacking-state.txt:49 talks about mgo/txn's "transactions" [02:41] yeah, i read that way back when [02:42] but they are not really transactions? [02:43] just sets/slices of db opps ? [02:44] yep === mwhudson is now known as zz_mwhudson [02:44] that's how i see it [02:45] okay, just double checking [02:45] thanks [02:45] i guess each slice of ops is a txn [02:45] but there are limitations compared with what you might expect from using other dbs === zz_mwhudson is now known as mwhudson === mwhudson is now known as zz_mwhudson [07:58] morning all [08:02] axw: can I bother you? [08:03] waigani: yep? [08:03] morning dimitern [08:05] hello all, has anyone ever run into a situation where juju-core (1.17.2 precise( thinks an environment is bootstrapped but can't destroy it because there are no instances? I tried removing the environments/ folder but no luck [08:06] hatch: the provider-state file is probably in cloud storage [08:06] what provider? [08:06] ec2, I'll take a look [08:07] axw: sync-tools. quick hangout? [08:07] hatch: if it happens again, try destroy-environment --force [08:07] waigani: sure [08:08] axw that was it! Thanks, I didn't know that it did that, I have been switching between trunk and devel a bunch so I wasn't sure if I broke something big :D [08:08] no worries [08:09] would be good to know why it happened, but that'd be difficult to figure out with no instances :) [08:09] I'll keep an eye open to see if it happens again [08:10] if the machines were destroyed out from under Juju (in the ec2 control panel) could that cause it? [08:17] hatch: that would cause it I think, but I can't tell if that's *the* cause [08:18] well after I'm done doing what I'm doing I can give it a try...might not be until later int he week though :) [08:20] no problems, thanks [08:33] axw, fwiw filed some new manual provider issues over the weekend (https://bugs.launchpad.net/juju-core/+bugs?field.tag=manual-provider&orderby=-date_last_updated&start=0) [08:34] hazmat: thanks, will take a look [08:34] hatch, yanking the provider-state in control-bucket should do the trick, there's an outstanding bug for this issue. basically juju should sanity check the instance id in object storage. [08:35] oy, I thought the reverse lookup was fixed [08:35] hatch, https://bugs.launchpad.net/juju-core/+bug/1176961 [08:35] ahhh thanks [08:35] axw, hmm.. i was going back and forth from trunk to 1.17.2 .. that one might have been against 1.17.2 [08:35] I had used --force [08:35] but good to know there is a known issue around this [08:37] hazmat: nah there's still a lookup in there, just in a different spot from before [08:40] hazmat: is https://bugs.launchpad.net/juju-core/+bug/1280432 on trunk? [08:41] axw, yes, but your pending branches may address [08:41] hazmat: https://bugs.launchpad.net/juju-core/+bug/1279259 [08:41] yeah [08:41] ok [08:41] axw, it looked like on upload-tools it was hardcoded to use ubuntu user before user was setup [08:41] modifying it to use configured bootstrap-user resolved it for me.. your fixes look more comprehensive [08:42] hazmat: what should happen is the ubuntu user gets initialised before any other ssh attempts are made; then ubuntu@ is hard-coded for everything else [08:42] only the ubuntu user init should use bootstrap-user [08:43] axw, i saw the logic, just not the reasoning, ie say we support centos ;-) [08:43] heh [08:47] hazmat: fwiw, the reasoning is: limit the number of times we request passwords from the user to one time during bootstrap [08:47] axw, btw, i was able to use some of the recent manual feature api additions to give a slick demo, of creating 50 lxc containers as env machines in under a minute, all offline [08:47] (once for ssh, once for sudo) [08:47] nice :) [08:47] oh, without apt-get stuff... very cool [08:48] axw, it needs a little setup (base images, btrfs) but the core comes out to just being roughly 20 lines.. https://github.com/kapilt/juju-lxc/blob/master/juju_lxc/add.py#L29 [08:48] axw, yeah.. it is pretty awesome, thanks :-) [08:49] oo, I hadn't seen juju-lxc [08:49] this looks like it'd be useful for my testing [08:51] axw, yeah.. its what i do dev with.. its not really cleaned up for easy consumption though, hoping to push some of it to tim's push to make local provider moar awesome. [08:51] hazmat: ah right, hence the talk of a plugin rather than local-specific. [08:52] axw, yup.. burnt my free time hacking on making digital ocean manual plugin easily consumable.. curious where that goes... i'll clean up the lxc plugin next time around.. but back to client work for the next few weeks. [08:53] enjoy ;) [09:01] jam: standup? [09:01] rogpeppe: yeah, 1:1 I was just making some lunch [09:06] rogpeppe, it's a little early to be standing up :P [09:21] dimitern: you're right, i'm sitting down [09:36] rogpeppe, can you ping me when you're done? I've got questions/ need some help when you have a moment [09:39] jamespage, ping [09:40] dimitern, hello [09:40] jamespage, did you get my last few messages? [09:40] jamespage, hey [10:00] axw, waigani: just responded to https://codereview.appspot.com/61520045/ -- thoughts? [10:10] fwereade: sorry dude, my only thought right now is that I can't keep my eyes open. I'll take a look in the morning. [10:10] waigani, np, sleep tight :) [10:32] fwereade: https://codereview.appspot.com/58510045/ is the current approach to debug-log, with support for local provider [10:35] TheMue, nice coincidence, I literally just got to that point in the review queue, probably won't do it until after standup though [10:36] fwereade: ok, have a new task where I have to read a lot first [10:36] TheMue, cool :) [10:47] rogpeppe, now's the time to stand up [10:47] ;) [10:50] wallyworld: are you coming back? we miss you! [11:41] * dimitern is out for 2h [13:01] trivial code review anyone? https://codereview.appspot.com/65050043/ [13:01] (it just sorts all imports consistently throughout the code base) [13:01] fwereade: ^ [13:10] * fwereade looks [13:11] rogpeppe, LGTM [13:11] fwereade: thanks [13:35] TheMue, half-reviewed https://codereview.appspot.com/58510045/ -- rogpeppe, would you take a look as well please? === gary_poster|away is now known as gary_poster [13:38] fwereade: thx [13:43] fwereade: regarding the public or internal params if I ask two of you I get three opinions. :) [13:44] fwereade: and all are one package, only different files. maybe a more general conceptual problem? [13:45] TheMue, haha [13:45] TheMue, what's the case for calling them internal? [13:45] TheMue, IMO if we expose them over the public API they're, well, public [13:46] TheMue, re files -- yeah, it's just convention I guess, but I think there's some value to spreading things out by file even if it's not compiler-enforced [13:46] fwereade: I had it in public before [13:48] fwereade: see https://codereview.appspot.com/58510045/diff/60001/state/api/params/params.go#newcode570 :) [13:48] TheMue, cheers [13:50] TheMue, I read that a bit differently to you, I think -- both the debug bits and the charms response should be in params, because they're both public api [13:52] fwereade: So you mean it should be moved inside the internal.go file? Otherwise, what does "Also, please move this in internal.go, where ..." mean? [13:52] TheMue, I think there was agreement in dimitern's second comment that they should both go in params, not internal [13:53] TheMue, he said params is fine, but please more CharmResponse [13:53] s/more/move/ [13:54] fwereade: OK, ic. [13:54] fwereade: But I won't move CharmResponse as the refactoring of those two extra handlers should be an extra CL. This one is already too large. [14:01] fwereade: i responded to some of your comments on https://codereview.appspot.com/58510045/ [14:14] rogpeppe: your way of letting all providers explicitly set the log location is less convenient but sounds logical and save [16:29] rogpeppe, hey, are you aware of the status of schema upgrades using the new upgrade framework? [16:29] dimitern: mongo schema upgrades? [16:29] rogpeppe, yep [16:29] dimitern: i think they're planned for, but i don't know when [16:29] rogpeppe, I know wallyworld did some work on upgrades in general, but is it usable? [16:29] dimitern: it only covers upgrades to stuff on a given machine [16:30] rogpeppe, hmm ok, so no schema upgrades yet [16:30] dimitern: the upgrades doc talks about mongo schema upgrades, but there's quite a bit of stuff yet to design [16:31] rogpeppe, i'm asking because of bug 1174610 which I've just fixed, but it involves some schema changes [16:31] <_mup_> Bug #1174610: unit ids should be unique

[16:32] dimitern: schema changes are essentially major-version upgrades [16:32] rogpeppe, I'll propose it provisionally for now, pending what needs to be done re schema upgrades [16:33] dimitern: how are you proposing to fix the problem? [16:34] rogpeppe, by using the sequence collection for unit ids, as we do for pretty much all other ids (machines, containers, etc.) [16:35] dimitern: so if you deploy wordpress, then deploy mysql, the first mysql unit is mysql/1 ? [16:35] rogpeppe, no [16:35] rogpeppe, the sequence name is "s#servicename#unit", so any service named "mysql" will have its units starting from 0 [16:36] dimitern: what happens now? [16:36] rogpeppe, e.g. if you deploy wordpress as mysql, then add a unit, it will be mysql/0, then destroy the service and deploy mysql with name "mysql", add a unit - it will be mysql/1 [16:36] rogpeppe, now unit ids start from 0 for each service [16:37] dimitern: ok, that's a little better [16:37] dimitern: it feels a little bit like a hack to get around the fact that our *service* names aren't unique though [16:37] rogpeppe, and apparently that's a regression from before, and some charms depend on using unit ids and them being unique [16:38] dimitern: the problem is that some other charms might depend on having a unit 0. [16:38] dimitern: (not that they should, of course) [16:39] rogpeppe, if there are any, it's not mentioned [16:44] hazmat, you'd be happy to know a fix for bug 1174610 is land very soon [16:44] <_mup_> Bug #1174610: unit ids should be unique

[16:44] rogpeppe, there it is https://codereview.appspot.com/64890044 [16:46] hazmat, s/is land/will land/ [16:48] dimitern: if it's not backwardly compatible without a schema change, i don't see how it can land [16:49] rogpeppe, it is compatible i think [16:49] rogpeppe, the problem is to update the sequences collection during the upgrade, so new units won't get ids starting from 0 [16:50] dimitern: exactly [16:50] dimitern: it's a major-version issue [16:51] dimitern: i'm wondering if there's a way to do it without the schema change [16:51] dimitern: or, without needing to synchronously update the schema anyway [16:54] dimitern, woot! [16:56] dimitern: for example, when a service is created, you could mark it with a "uses global sequence numbering" flag [16:56] rogpeppe, yeah? [16:56] dimitern: when a service is destroyed that doesn't have that flag set, it could update the sequences collection with the most recent unit number for that service [16:56] rogpeppe, isn't that a schema change as well? [16:57] dimitern: when a unit is created, if allocates it from the service sequence number unless the "uses global sequence" flag is set [16:57] rogpeppe, ah, one of those flags where false is default [16:57] dimitern: yes [16:57] dimitern: in that way, you can remain compatible with the old schema but update to the new schema over time [16:57] rogpeppe, well, that could work, but how about service creation? we always create services with this flag=true [16:58] dimitern: yes [16:58] rogpeppe, ok, i'll look into it tomorrow, i'd appreciate these comments in the review please :) [16:58] dimitern: so only legacy services will have that flag==false [16:58] dimitern: ok, will do [16:58] rogpeppe, ta! [17:44] davecheney, btw a new gccgo-4.9 snapshot is working its way into trusty; I've rebuilt gccgo-go and juju-core using this new version [17:44] its the default (gccgo -> gccgo-4.9) [18:27] trivial code review, anyone? https://codereview.appspot.com/65160043/ === BradCrittenden is now known as bac [18:37] rogpeppe: will look in a sec [18:37] mgz: ta === zz_mwhudson is now known as mwhudson === mwhudson is now known as zz_mwhudson