[00:04] arosales: ping [00:04] wallyworld: ping [00:06] morning [00:10] jamespage: ping, [00:10] thank you for uploading 1.11.4 into saucy [00:10] any issues ? [00:36] * thumper waves [00:39] thumper: if we branch 1.12 [00:39] is the bot going to be able to cope with this ? [00:39] NFI [00:40] survey says: fuckup [00:44] thumper: do I need to wait for william on branching 1.12 [00:44] or do you speak for him ? [00:44] or in fact does he speak for you ? [00:44] :) [00:44] it is hard to make him out, from his exhaultedly high architects chair [00:44] william is on holiday [00:44] if we need it done now [00:44] do it [00:45] I'll take any heat - although I expect only the good kind [00:45] we don't need to do it _RIGHT_NOW_ [00:45] but it feels like the right time [00:45] do it [00:45] and that way we can have a stable release in backports when you go to Isle of Man [00:45] this bit was imporant to Mramm [00:45] * thumper nods [00:45] important either [00:53] sodding, shit [00:54] the bot will have to own the series branch right ? [01:06] davecheney: why do we want a bot controlled series branch? [01:07] so the bot owns juju-core/trunk [01:08] is it ok for ~gopher/juju-core/1.12 to be a thing ? [01:09] sure is [01:10] /s/gopher/gophers or whatever our team is called [01:10] ok, let me see if I can figure out how to do that [01:11] where can I list the series for a project ? [01:11] apart from the graphy thing on the front page ? [01:12] ah, ok, i think i have it now [01:21] hey folks. does whatever bot that does the merging not also update bug status to "fix committed"? [01:21] is that a manual step? [01:22] also, is there an up-to-date doc describing merge procedures? cos CONTRIBUTING talks about lbox submit, which apparently isn't used anymore [01:23] axw: the bot should mark linked bugs as committed, yes [01:23] but they have to be linked to the branch [01:24] errr not the bot sorry, Launchpad's branch scanner will do it [01:24] when it sees the branch merged [01:24] CONTRIBUTING needs fixing, as you noticed :) [01:25] I assume that would've run in the last 12 hours [01:25] https://code.launchpad.net/~axwalk/juju-core/lp1203935-ec2-octal-prices/+merge/176315 [01:25] is merged [01:25] yes [01:25] but the bug is still in progress [01:25] * bigjools looks [01:25] but... the mp says pending? [01:26] huh what's up here [01:26] oh the pending is because reviews are done on shiteveld not LP, so there's no approvals on the MP itself [01:27] lbox should do that really [01:28] what am I saying, lbox should die [01:28] :) [01:28] * thumper tries to focus [01:29] is the pending status stopping the scanner from updating the bug? [01:29] or something else is wrong? [01:30] axw: not entirely sure, thumper might know? [01:30] (he wrote most of that code) [01:30] * thumper looks up [01:30] bigjools: nps, thank you [01:30] ah [01:30] thumper: my MP is merged, but the bug wasn't automatically updated [01:30] thumper: branch scanner has not set fix committed on a linked bug where the branch is merged [01:30] curious what I did wrong, or missed [01:30] LP has never done that AFAIK [01:31] but people wrote scripts [01:31] really? [01:31] really [01:31] does tarmac do it? [01:31] I think so [01:31] I've seen it done [01:31] ah [01:32] tarmac? [01:32] axw: was the bug linked before marking the MP approved? [01:32] Tarmac is the landing bot code [01:32] bigjools: yes [01:33] ok so either it's a bug in Tarmac or something else is wrong, but no idea what! [01:33] mkay [01:33] I've definitely had this working on other projects [01:33] never mind, not a big deal for now [01:33] yeah, you can manually mark it [01:44] bigjools: how do I branch from a tag ? bzr branch -r ... lp:... ? [01:45] davecheney: bzr help revisionspec [01:45] bzr branch -r tag:BLAH lp:thing [01:45] thank you [01:46] i would grumble that every dvcs has a different convetion for rev specs [01:46] but actally i'm just a dumpass [01:46] dumbass [01:46] heh, np [01:46] bzr's help is actually very good, I reckon [01:48] thumper: would you think it is safe to say to #eco that 1.12 won't have the worlds best local provider, and they should follow 1.13 ? [01:49] who is #eco? [01:49] um... world's best? it is likely to get continual improvements [01:49] hopefully we won't be too long between non-dev releases [01:49] #eco is m_3 marcoceppi etc, who lurk elsewhere [01:49] so 1.14 should be soon enough (I hope) [01:50] o/ [01:50] to be more specific, 1.12 (stable) won't see a lot of lxc fixes [01:50] we'll deliver a better version in 1.14 [01:50] correct [01:50] thumper: cool, thanks for clarifying [01:50] I don't see us spending much time fixing things in 1.12 [01:50] * davecheney has given up trying to branch locally [01:50] too slow on this tiny internet [02:00] https://launchpad.net/juju-core/1.12 [02:35] davecheney: add a trunk series and you'll get a prettier graph [02:36] oh wait there is one, ignore me [02:37] bigjools: pretty isn't the word i'd use for it :) [02:37] elongated springs to mind [02:37] I did say "prettier".... it's all relative :) [02:38] it reflects your lack of release branches though [02:38] bigjools: if you squint, the shape looks like a cowboy hat [02:39] so.. I might be full of crap, but it seems that one of the cmd/juju tests is a bit wrong/broken [02:39] UpgradeJujuSuite.TestUpgradeJujuWithRealUpload always builds tools from the trunk [02:39] davecheney: seems appropriate [02:39] axw: wouldn't surprise me [02:39] is this intended? [02:41] axw: probably not [02:43] actually [02:43] I am full of crap [02:43] ignore me [02:53] axw: glad you figured it you :P [03:05] * thumper might do some more clean up of code [03:05] been writing documents [03:20] urgh, lunch coffee tastes like armpit [03:39] thumper: pingy ping [03:39] wallyworld_: hey [03:40] so, i've finally done some work in my validation branch to satisy rogr hopefully. to do it as a plugin.... i was thinking i'd make a plugin dir, add the cmd in there, and update the release scripts [03:41] wallyworld_: hmm... sounds interesting... [03:41] however [03:41] so the juju-foo binary is put in the deb [03:41] the point I raised about doing it as a plugin is to keep it out of the tree [03:41] and out of band [03:41] if you are just going to put it into the tree and build a binary and ship it [03:41] i think it belongs in the tree [03:41] just keep it in the freaking tree as a command [03:42] ok [03:42] it makes zero point to have a plugin in the tree [03:42] it belongs in the tree because the validation is tied to the version of juju [03:42] command is best IMO then [03:42] ok [03:43] another trivial gc prefix branch https://codereview.appspot.com/11754043 [03:43] when i say tied to..... it's not right now but there may well be thinsg we build into the metadata that only later version of juju can rad [03:43] read [03:44] wallyworld_: that's good enough for me [03:44] ok, ta. will re-propose [03:48] I have a failing test locally, what is wrong here folks? http://pastebin.ubuntu.com/5906306/ [03:49] bigjools: "-":"0" [03:49] ^ weird key in the map [03:49] yeah - nothing I changed either [03:51] bigjools: o_O, where does the "-" leak in from status ... [03:53] I dunno, I know very little about this stuff [03:54] * davecheney runs tests [03:56] I suspect a local setup problem but I've no idea how to work out what [03:56] the test looks fragile [03:59] bigjools: it is [04:00] i tried to use the same test harness to validate both json and yaml outputs [04:01] thumper: you free for a hangout sometime? [04:01] hey gang, anyone have a quick pointer to syntax for 'relation-get' from within a hook? I'm looking for args [04:01] m_3: shoot [04:01] what have you tried ? [04:01] * davecheney goes to look at the source [04:03] wallyworld_: sure, if you don't mind getting interrupted by me being a manual gps service [04:03] getting breakage from... popen("relation-get --format json - $node", 'r'); [04:03] thumper: it can wait till you're free [04:03] davecheney: I'm guessing that I can't pass in the unit-id [04:04] m_3: - $node looks suspect [04:04] yeah [04:04] did you mean -- $node ? [04:04] wallyworld_: ok [04:05] ahh, this is interesting [04:05] if c.Key = args[0]; c.Key == "-" { [04:05] c.Key = "" [04:05] } [04:05] davecheney: nope, the syntax was a single '-' apparently [04:05] looks like we consume it and remove it [04:05] m_3: do you have more context [04:05] one line isn't helping with language either [04:06] thumper: from within a hook, you'll typically call `relation-list` [04:06] thumper: then loop on the results of that and do a `relation-get --format json - $remote_unit` to get info for each of the related units [04:07] m_3: right, so I'm assuming bash? [04:07] actually python [04:07] in which case the $ looks wrong [04:07] popen("relation-get --format json - $node", 'r'); [04:08] m_3: can you pastebin the whole thing? [04:08] sure [04:08] hahaha [04:08] ok, sorry... php [04:08] fuck my life [04:08] mediawiki charm... lemme find the link [04:08] m_3: that's going on the quotes page [04:09] but really, I'm guessing something changed between py and go wrt this '-'? [04:09] do we expect the current relation get to accept a unit-id? [04:10] pls hold, bootstrapping [04:10] actually, don't need to do that [04:11] thumper: context... http://bazaar.launchpad.net/~charmers/charms/precise/mediawiki/trunk/view/head:/hooks/slave-relation-changed [04:11] do you guys have any details for the Brisbane induction sprint? [04:12] bigjools: no, i was going to ask you [04:12] heh [04:12] i'd good to see we're sticking to the code [04:13] the first rule of induction club ... [04:13] indeed, arrive at unknown destination, begin a linear search for your hotel [04:14] * bigjools emails persons [04:15] m_3: dude, that is PHP! [04:15] not python [04:15] right [04:15] lulz [04:15] was only looking at the system call to relation-get, not the surrounding code [04:16] * thumper vomits a little into his mouth [04:16] * m_3 cries [04:16] $node now makes sense [04:16] but I can't help you [04:16] but really, the same thing is done in bash and python in other charms [04:17] relation-list... relation-get - unit-id [04:17] sure... [04:17] my lack of ability to help is more around NFI what the actual commands do [04:17] or return [04:17] etc [04:17] :) [04:18] yeah, I'll start grepping through core [04:18] I do think it is funny that one uses exec [04:18] the other popen [04:18] to do the same shit [04:18] I'm not even going to start on that [04:18] heh [04:19] wallyworld_: https://plus.google.com/hangouts/_/2e05ac3602809a0997b9970e5bf785f4c607e745?hl=en [04:22] same from the old code [04:22] if self.options.settings_name == "-": [04:22] self.options.settings_name = "" [04:22] this - thing is a noop [04:23] buuuuuut, i wonder if gnuflags parses it correctly ... [04:35] I think I'm just gonna punt on this one. I'll find some other stack that's working and pretty to look at in the gui [04:35] thanks for the help [04:51] m_3: shit [04:51] that sucks [04:51] please log a bug [06:33] davecheney: is there a place we can store environment bootstrap data? we need the same data at env teardown time [06:33] bigjools: i'm thinking JUJU_HOME [06:33] we put a lot of other crap in there [06:33] ssl certs [06:33] caches [06:33] directory? [06:34] yup [06:34] on the client? [06:34] yes [06:34] maybe I misunderstood your question [06:34] I mean user's machine [06:34] what happens if they do stuff from a different machine later [06:34] What we need to store is information about resources on the cloud that we've allocated as part of setting up the environment. [06:34] So it has to be centralized. [06:34] what he saud === jtv2 is now known as jtv [06:35] said [06:40] davecheney: nowhere centralised then? [06:40] davecheney: can the provider update its own config for this sort of thing? (It happens to be a configurable resource — provided by the user or allocated by the provider) [06:46] bigjools: the two options are [06:46] ~/.juju and the state [06:46] jtv: yes, in theory [06:46] in practice no, it porbably doesn't have access to the state [06:47] ~/.juju is a non-starter really [06:47] oh sorry [06:47] one more place [06:47] * davecheney smacks head [06:47] the private bucket [06:47] otherwise destroy-environment would not work except on your original client [06:48] bigjools: it is unlikely anything will work except on the original client [06:48] private bucket dear liza [06:48] srsly? [06:48] if the user does not have a whole copy of ~/.juju [06:48] The private bucket... I guess that's the EC2 equivalent of our storage account & container. [06:48] no certs baby [06:48] so if you local machine loses its HD .... ? [06:48] your* [06:48] you are royally fucked [06:48] !!! [06:48] dafuq [06:52] private bucket means you'd need to know the data to get the data ... [07:06] bigjools: i can tell that you and I are going to get on like a house on fire in BNE [07:06] me telling you things [07:06] you trying not to hit me [07:13] that wasn't me cutting his internets, honest === tasdomas_afk is now known as tasdomas [07:35] bigjools: what environment bootstrap data do you want to store? [07:39] rogpeppe: otp, back in a while [07:42] bigjools: okeydoke [07:51] rogpeppe: right [07:52] rogpeppe: when we bootstrap, we have to create some storage account objects that need naming [07:53] we're configuring that to use existing storage accounts at the moment but there's also no reason why they can't get created by bootstrap code [07:53] but if we do that we also need to delete them when destroy-env runs [07:54] bigjools: i think the private bucket is exactly what you need here. it's where (for instance) the id of the bootstrap instance is stored. [07:54] bigjools: so the bootstrap code already writes there [07:54] rogpeppe: I was worried we had a chicken and egg situation [07:54] bigjools: i don't *think* so... [07:55] is the private bucket creds/details cached somewhere? [07:55] bigjools: you name the private bucket in your environments.yaml [07:55] bigjools: what about creating the storage with a fixed name, derived from the environment name? This way we won't need to store the name anywhere, because it can be derived from the env name. [07:55] rogpeppe: can't do that, it has to be globally unique [07:55] rvba: that's exactly how the private bucket works [07:56] err rvba sorruy [07:56] bigjools: that's the same as the ec2 private bucket [07:56] bigjools: you need to choose something globally unique [07:56] bigjools: is that a problem? [07:56] azure creates a DNS entry out of your account name [07:56] storage account I mean [07:57] would you like to guess how many people are going to call their environment "azure" [07:57] so yes it's a problem :) [07:57] I see :) [07:57] bigjools: how about adding a config entry to the azure environments.yaml: global-environment-name, or something [07:58] rogpeppe: could make it a {{rand}} [07:58] bigjools: yeah, that would probably be a good default [07:58] we did consider this earlier, but there is a snag [07:59] if someone wants to re-use an existing storage account instead of having juju create one on the fly, how do we know whether to delete it or not later? [07:59] bigjools: two possibilities there [08:00] bigjools: 1) if we create the account at bootstrap time, mark the private data with "this needs cleaning up", and clean up the account at destroy-environment time only if that flag is set [08:01] bigjools: 2) just delete it regardless and document that juju always requires its own storage account [08:01] bigjools: for 2) you could probably do some sanity checking to make sure there's nothing in the account that you wouldn't expect to be created by juju [08:01] rogpeppe: if the former, where can we store a flag? [08:02] bigjools: in the private bucket? (which presumably is in the storage account) [08:02] inside storage accounts, you have another layer of indirection called a container, BTW. These are separately public and private. [08:03] bigjools: hmm [08:03] fun isn't it :) [08:03] there's a pricing implication as well I think, which is why I am being careful [08:04] bigjools: the container name space is within a storage account, or global? [08:04] we took the cheap way out at the moment and made configuration of an existing account/container mandatory [08:04] within the account [08:04] bigjools: ah, you pay for a storage account? [08:04] I'm not sure but I expect so [08:05] bigjools: can you delete a storage account if it has containers? [08:05] no [08:06] anyway I think we can write a file to the private storage for now [08:06] it will suffice [08:07] thanks for the advice [08:07] bigjools: hmm, this might work: at destroy-environment time, you destroy the private bucket(container) and try to delete the storage account. if it fails because there are containers, ignore the error. [08:08] bigjools: this assumes that there's no other useful stuff attached to an account, i guess [08:08] well if someone created a storage account and didn't put any containers in it yet, they would get a surprise [08:08] bigjools: yeah, but they'll have named the account in their juju environments.yaml, and hopefully this behaviour is documented. [08:08] rvba: I was thinking - we might *have* to create a container on the fly to ensure it's private [08:09] bigjools: or... [08:09] bigjools: maybe there is a way to check if a container is private and issue a warning or even an error if it's not. [08:09] rogpeppe: well I personally dislike surprises like that, it ought to be simpler. I think we can make it simple. [08:09] bigjools: add a "do-not-delete-storage-account" attribute to environments.yaml, i guess [08:10] rogpeppe: jtv came up with that one too, I accused him of coming up with a developer solution and not a user solution :) [08:10] bigjools: the wrinkle that i see is that several juju environments might use the same storage account, presumably [08:10] rogpeppe: correct [08:12] bigjools: so i guess the question is: what semantics do we want? do we want the storage acct to be destroyed after the last environment is destroyed in the acct? [08:12] bigjools: but only if the account was created automatically [08:13] rvba: rogpeppe: my ideal scenario is to delete only if created automatically. [08:13] and that is decided by whether you configure it or not [08:13] Sounds like the best story from a user pov. [08:13] indeed [08:13] bigjools: don't you have to configure it, otherwise you won't know how to find the private bucket? [08:14] bigjools: assuming the private bucket is addressed relative to the storage account [08:14] right [08:14] so.... seems like we can't do this then === racedo` is now known as racedo [08:14] privacy is defined at the container level, not the account [08:15] so if a private "bucket" is required in the config up front, we can't auto-generate anything can we? [08:15] this is my chicken and egg question from earlier [08:17] bigjools: how about this: you must specify the storage account name. within that, the private bucket is named after the environment name. if the storage account does not exist, it's created, but we never remove a storage account. [08:18] could work [08:18] bigjools: i think that's a clear story to the user with minimal magic [08:18] indeed [08:19] mgz: ping [08:20] rvba: what do you think? [08:30] rvba is too busy deploying juju-gui on azure :) === vorpalbunny is now known as thumper [08:30] * thumper wanders off for a bit === thumper is now known as thumper-afk [08:30] rogpeppe: I /think/ it is… and that's why leaving an account after auto-creating it is a bit nasty. [08:30] heh [08:31] rvba: on the other hand, perhaps it's nice for a user to still have around the account that incurred the billing [08:32] rvba: the user is explicitly naming it after all. [08:33] rvba: we should find out definitively the cost implications of having a storage account [08:35] * rvba otp [09:03] rogpeppe: you're right, that's really the deciding factor. [09:03] bigjools: ^ [09:04] rvba: let's go half way for now and auto-generate the containers [09:04] named after the environment [09:04] auto generating storage accounts is fraught with problems === allenap` is now known as allenap [09:32] bigjools: that seems reasonable to me. a decent error message ('Juju storage account "foo" not found - please create it and try again') could help, and make things less obscure to the user [09:36] mgz ping === thumper-afk is now known as thumper [09:37] wallyworld_: got a moment to introduce me to the wonders of simplestreams? [09:41] thumper: pong [09:41] mgz: hey there [09:41] mgz: got any voip capabilities? [09:41] either hangout or mumble [09:42] your pick === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: thumper | Bugs: 5 Critical, 76 High - https://bugs.launchpad.net/juju-core/ [10:12] rogpeppe: ping [10:12] dimitern: pong [10:13] rogpeppe: hey, so the deployer needs to know state/API addresses for the simple context [10:13] rogpeppe: I missed that before, do you think we should have both in the deployer facade? [10:14] dimitern: yes, i think so [10:14] rogpeppe: and just return whatever's there in state [10:14] dimitern: yeah [10:14] rogpeppe: ok [10:14] rogpeppe: and CACert as well [10:15] dimitern: yes [10:15] rogpeppe: isn't this a security issue? [10:15] rogpeppe: maybe not, because it's the public cert [10:15] dimitern: exactly [10:15] rogpeppe: ok then [10:16] dimitern: we'll also need to provide the private key too, but only to nodes which are configured to run the state server. [10:16] rogpeppe: and there's no deployer there usually, right? [10:17] dimitern: there might be. i don't think we mind too much at this level. [10:17] rogpeppe: but it's not part of the deployer api [10:18] dimitern: the deployer wouldn't need the private key. i think that would probably be something for the machineagent API [10:18] rogpeppe: right [10:22] jtv: sorry, i was at soccer training and am about to go out again. tomorrow [10:22] Ah. [10:22] dimitern: i'm going out for a late dinner and a movie so will miss the meeting [10:23] gnight [10:35] wallyworld_: ok [10:35] wallyworld_: is there a rising trend there? :) kidding [10:38] i'm looking for a review on https://codereview.appspot.com/11723043/ if anyone cares to take a look [10:47] rogpeppe: looking [10:51]