[00:07] natefinch-bed: night === gary_poster is now known as gary_poster|away [04:24] sinzui: rogpeppe: generally you get the ghost revision doing a lightweight checkout of a stacked branch (with no actual local commits). The easier thing is "bzr reconfigure --unstacked lp:gnuflag" [04:24] I would expect a trunk branch to be unstacked anyway, but I can imagine the owner changed over time [04:26] go bot will mark things Fix Committed if you used "bzr commit --fixes lp:####" I believe [04:29] I guess I missed that you did eventually figure that out [04:29] morning jam [04:30] morning axw, I'm not "officially working" but if I can do anything to smooth the release I'll sneak some time this morning. Do you know of anything ? [04:30] jam: nope, was just saying morning :) [04:31] I'm not aware of any problems [04:31] axw: and a good afternoon to you [05:44] argh, something has broken the null provider [06:44] axw: does storage-auth-key have a default value ? [06:44] davecheney: no, it is in the boilerplate with a random value, but there's no default [06:45] it should be checked for existence [06:45] but isn't [06:45] how come you were able to comment it out [06:45] ? [06:45] oh, you just told me [06:45] well, there is your problem [06:46] bleh, I found another problem, and this one actually does need a code fix :( [06:48] dag [06:48] dang [07:03] mornin' all [07:04] jam: i didn't know about bzr commit --fixes [07:04] axw: what's the problem? [07:07] rogpeppe: https://bugs.launchpad.net/juju-core/+bug/1235100, https://bugs.launchpad.net/juju-core/+bug/1235102 [07:07] <_mup_> Bug #1235100: null provider machine agent fails to initialise [07:07] <_mup_> Bug #1235102: null provider authenticating storage client fails [07:08] I made some changes in a review, and broke everything [07:08] didn't do a live test [07:09] (everything in the scope of the null provider only) [07:10] axw: the storage-auth-key panic looks like the null provider isn't checking its config properly [07:10] rogpeppe: correct [07:10] I know what all the issues are, they just need code changes [07:10] which obviously isn't good at this time :) [07:11] axw: well i'm happy to review [07:11] night all [07:11] i'll be online later [07:11] rogpeppe: cool, trying to get it all working now. I'll ping you a bit later [07:11] night davecheney [07:11] davecheney: see ya [07:19] hey all [07:20] I see no release, so I presume things are bad [07:24] fwereade_: not sure why there's no release, but things are bad with the null provider.. wouldn't think that would hold anything up tho [07:25] also, hi [07:25] axw, heyhey [07:25] axw, well, that is rather problematic tbh, is there anything I can do to help? [07:25] fwereade_: under control at the moment, just about to propose a couple of fixes [07:26] axw, ok, cool [07:37] rogpeppe, fwereade_ https://codereview.appspot.com/14387043 [07:37] one more to come [07:39] axw: just remind me please: when is the machine agent accessing the environ's Storage before the secrets are pushed? [07:39] axw, sorry, I don't quite get it [07:39] axw, yeah, what rogpeppe said [07:40] I think it was from StateInfo [07:40] one moment, I'll reproduce [07:42] rogpeppe, fwereade_ yep, environ.StateInfo gets called, which calls common.StateInfo, which does a common.LoadState [07:42] axw, by what? [07:43] launchpad.net/juju-core/state/apiserver/common.(*Addresser).StateAddresses(0xc200263d00, 0x0, 0x0, 0x0, 0x0, ...) [07:43] axw: isn't the StateInfo passed to the machine agent in its config? [07:44] axw: i'm a bit surprised that the machine agent is calling StateInfo before it has a valid environ config [07:44] rogpeppe: as was I :) [07:44] axw: where is it being called? [07:45] rogpeppe: I'll pastebin the stacktrace, just a sec [07:45] rogpeppe: http://paste.ubuntu.com/6191212/ [07:46] axw: could you paste the stack trace of the bootstrap machine agent at that point? [07:46] rogpeppe: ? that is from the bootstrap machine agent [07:47] axw: i mean the stack trace of all the goroutines [07:47] ah yep, just a sec [07:48] axw, so that's either deployer or provisioner making that call, right? [07:48] axw, deployer shouldn't have any units to deploy until after the first connection [07:48] the bot was running out of space and there were way too many gocheck-* and test-mgo* dirs in /tmp/ so some tests were failing, I just cleaned it up [07:48] axw, and provisioner shouldn't start until it's got a valid environ config [07:48] dimitern, thanks [07:49] fwereade_: not sure tbh. I just bootstrapped and nothing else [07:49] so it shouldn't be trying to provision anytthing [07:50] axw, sure, but the provisioner ought to be able to start up with an invalid environ config, and just sit and wait until it gets a valid one [07:50] fwereade_: agreed; i think it must be the provisioner [07:50] fwereade_: yeah, I thought it did wait today [07:50] axw: still waiting for that stack trace - it'll sort out whether it's the provisioner or the deployer [07:50] I was looking at it earlier, looked somewhat sane [07:50] rogpeppe: uploading now [07:50] perhaps it's a bug in WaitforEnviron [07:51] axw, does a config without a storage-auth-key validate? [07:51] axw, it looks like it does, and that's the problem,but maybe I'm misreading [07:52] fwereade_: it does at the moment. If nothing is meant to be able to call Storage until it has all the secrets, then it shouldn't validate [07:52] rogpeppe: attached machine-0.log to https://bugs.launchpad.net/juju-core/+bug/1235100 [07:52] <_mup_> Bug #1235100: null provider machine agent fails to initialise [07:53] axw, that schema.Omit is basically an explicit "I don't care if we don't have this, everything will work perfectly if it's not here" [07:53] axw, and unless there's some explicit handling elsewhere to fail validation, there's your problem [07:53] fwereade_: yep, I understand that bit [07:53] (now) [07:53] ;) [07:53] :) [07:54] nothing like a last minute bug to educate you [07:54] anyway [07:54] oh yes indeed:) [07:54] I'll propose this other fix, then get back to this issue [07:54] axw, cheers [07:58] fwereade_: https://codereview.appspot.com/14388043 [07:59] this one's more straight forward [08:00] axw, I am concerned at the lack of tests there... [08:00] axw, I can't really see the impact by inspection [08:01] fwereade_: ok. I think I can come up with one [08:01] axw, thanks [08:08] hi, how can I create local certs in juju home for an environment? [08:09] fwereade_: updated, verified it failed before the fix [08:11] rogpeppe: I think it's triggered by the provisioner task calling NewAPIAuthenticator, which does st.StateAddresses [08:11] rogpeppe: the API server gets the env config from state, but the secrets aren't in there [08:12] axw: but it shouldn't be calling NewAPIAuthenticator until it's obtained a valid Environ [08:12] axw: which shouldn't be possible until the secrets are there [08:12] rogpeppe: ok, so is it because Validate isn't returning an error [08:12] ? [08:12] axw: that sounds right [08:13] axw: i think that's what fwereade_ was trying to say earlier [08:13] right, I didn't catch on [08:13] I'll fix that now. thanks rogpeppe and fwereade_ [08:14] frankban, if you started a new environment with current code, the certs are now written into BootstrapConfig in $JUJU_HOME/environments/.jenv [08:19] fwereade_: thanks, that's right. In trunk, if I add a new environment (e.g. a local one) in the yaml file, and then I try to bootstrap it, the certs seems not to be generated: http://pastebin.ubuntu.com/6191312/ [08:21] I think that's a real bug with the local provider [08:21] it used to have to chown the cert files to the sudo caller [08:23] frankban: as a workaround, you can "touch" that file it's complaining about. would you mind logging a bug? [08:24] rogpeppe: updated https://codereview.appspot.com/14387043 [08:26] frankban: never mind, I'll log it - I can reproduce it trivially [08:27] axw: thanks! [08:27] https://bugs.launchpad.net/juju-core/+bug/1235130 [08:27] <_mup_> Bug #1235130: local provider fails bootstrapping if legacy certificates are missing [08:28] frankban, axw: ah sorry about that - my fault, i had no idea there was other stuff in the system that relied on the old cert files [08:28] should be trivial to fix [08:28] rogpeppe: no worries, it's a bit specific to the local provider [08:28] yep [08:29] * rogpeppe thinks that our approach to dealing with the running-as-root stuff is a bit wrong [08:29] i think we should run *something* as root, but drop privileges a.s.a.p. [08:30] then we wouldn't need the "chown it back to what we think it should have been" hacks all over the place [08:30] it's not great [08:34] fwereade_, axw: so, IIUC, excluding that bug we could safely remove all the pem files in JUJU_HOME, correct? [08:35] frankban: I think it'll need to be migrated to the .jenv file first, is that right rogpeppe ? [08:35] frankban, not for pre-existing environments [08:35] fwereade_: +1 [08:36] axw, frankban, rogpeppe: we don't have any migration code there but we probably should:( [08:36] it's a bit awkward at the moment [08:36] doh [08:36] fwereade_: i was wondering about that [08:36] * axw undoes his current change ;) [08:36] fwereade_: it's not *strictly* necessary, but would enable us to have cleaner code [08:36] fwereade_: and better error messages [08:37] the error you get when trying to talk to an environment without associated environ info is terrible currently [08:38] fwereade_: how about "juju make-info -e someenv" ? [08:39] rogpeppe, wait, so we can't keep using an existing environment? [08:39] fwereade_: sure we can [08:39] rogpeppe, thought so [08:39] rogpeppe, but then I don't follow what you just said [08:40] fwereade_: but the problem is that if you have a new-style environments.yaml, you get an error like this http://paste.ubuntu.com/6191378/ [08:41] fwereade_: because the code thinks that if no info exists, it must try to make a valid environment from just the attrs in environments.yaml [08:41] rogpeppe, ah, so that's trying to destroy twice? [08:42] fwereade_: it doesn't get that far [08:42] fwereade_: it fails trying to make a new Environ [08:42] rogpeppe, sounds like it's doing more than it should [08:42] fwereade_: (i tried to raise this with you yesterday, BTW :-]) [08:43] rogpeppe, but only when that environ doesn't exist? [08:43] dimitern: what do you think it should do? [08:43] fwereade_: only when the configstore info for that environ doesn't exist [08:43] rogpeppe, sorry I either missed it orcompletely failed to understand [08:43] rogpeppe, check if there's an actual bootstrapped environment before trying to prepare one? [08:44] dimitern: this problem doesn't happen when Preparing [08:44] dimitern: it'll happen if you call juju status, for example [08:44] dimitern: or any command that tries the NewFromName an existing environment [08:44] s/the/to/ [08:44] rogpeppe, or destroy-environment [08:45] dimitern: yeah - that was my original example [08:45] rogpeppe, but only if that environment has been edited to become new-style..? [08:45] fwereade_: yes [08:45] rogpeppe, yeah, that seems just little too magical [08:45] fwereade_: the problem is our attempt to deal with the old-style environments.yaml [08:45] rogpeppe, the release notes have: [08:46] admin-secret is now chosen automatically if omitted from the configuration of a new environment. [08:46] control-bucket is now chosen automatically if omitted from the configuration for new ec2 and openstack environments. [08:46] rogpeppe, the same thing happens when you upgrade from 1.14 - no new-style env info [08:46] dimitern: yes [08:47] rogpeppe, dimitern: so, it's all about environs that were bootstrapped pre-1.15 [08:47] what i would *like* to happen is that these commands just fail immediately if there's no associated environ info [08:47] fwereade_: yes [08:47] rogpeppe, dimitern: and which have then been destructively edited in environments.yaml [08:47] rogpeppe, dimitern: is the behaviour actually any worse than would happen in 1.14 if you broke environments.yaml? [08:47] fwereade_: hence my thoughts about a transitory "juju make-info" command [08:48] fwereade_: no, it's not about envs which have then been destructively edited [08:48] fwereade_: it's about envs which have *not* been destructively edited [08:48] fwereade_: that's what the code is currently trying to deal with [08:48] fwereade_: and that should work fine [08:49] fwereade_, no sure what you mean by destructively edited [08:49] rogpeppe, what happened to the control-bucket in the example you pasted? looks like a destructive edit to me..? [08:49] fwereade_, if you remove the environment from env.yaml? [08:49] fwereade_: that's not an environment that was bootstrapped pre-1.15 [08:49] rogpeppe, ahhhhh bollocks ok [08:50] rogpeppe, but then I don't see how make-info would help [08:50] fwereade_: make-info would create the environ info (with bootstrap config) from an environments.yaml file [08:51] another CL, to fix the local provider issue: https://codereview.appspot.com/14289044 [08:51] fwereade_: so we could change the code to fail *always* if an appropriate .jenv file does not exists [08:51] exist [08:51] fwereade_, axw, rogpeppe: thanks for your help. I believe you are already aware of this, but, while local envs now work properly in my raring box, I also see those errors: http://pastebin.ubuntu.com/6191399/ [08:52] aw ffs [08:52] frankban: yep, I believe rogpeppe has fixed that last night [08:52] frankban: that's with trunk? [08:52] frankban, thanks [08:52] axw: i *thought* i fixed that [08:52] oh [08:52] :o [08:52] rogpeppe: yes, revno 1948 [08:53] frankban: but you're still seeing that problem? [08:53] rogpeppe: yes [08:53] rogpeppe: I can confirm [08:53] bugger [08:54] * rogpeppe goes to fix it [08:54] rogpeppe, you did run the local provider with your fix, right? [08:54] fwereade_: i did, but perhaps not with the final combo [08:55] rogpeppe, heh, I've fallen into that one acouple of times [08:55] bad luck [08:55] rogpeppe, but when scrambling for a release it's doubly important to be obsessive [08:55] fwereade_: yes [08:58] well, the bug is clear; i wonder why my test didn't find it [08:58] rogpeppe, basically I am not happy with the make-info idea, but let's come back to it in a bit [08:58] fwereade_: yeah, it was a straw man; other ideas would be good. [09:12] fwereade_, axw, frankban: here's the (possible) fix - am just verifying it works with the local provider:https://codereview.appspot.com/14388044 [09:15] rogpeppe: cool thanks [09:15] rogpeppe: looking [09:15] rogpeppe, LGTM if it works [09:15] ah already [09:17] rogpeppe, fwereade_: let me know if there's anything that needs explaining in my CLs... just going to make a cup of tea [09:21] fwereade_: it works [09:22] rogpeppe, great [09:22] fwereade_: i'll land that and then fix the cert chown problem [09:23] rogpeppe, axw has https://codereview.appspot.com/14289044/ up, take a look at that [09:24] fwereade_: great [09:24] fwereade_: that's exactly the change i was gonna make [09:26] fwereade_: so, back to make-info (or whatever); there's another possibility, that i'm less keen on because it's kinda wrong, but... [09:27] fwereade_: which is to change environs.NewFromName so that if the environment or config can't be made and there's no environ info, it just returns "environment does not exist", ignoring the config error [09:28] rogpeppe, so, I think I'd be happier with that [09:28] rogpeppe, but I expect you've thought through the problems more clearly than me [09:32] fwereade_: it always seems a bit bad to ignore arbitrary errors, but i think in this case it's ok - we're grudgingly allowing some legacy environments to be created, but ignoring them if they're invalid [09:33] rogpeppe, yeah, that was my readingof it [09:33] fwereade_: ok, i'll propose something that does that [09:34] fwereade_: i think it's worth getting in if we can [09:34] fwereade_: because everyone will come across this problem [09:35] * fwereade_ hates churn at this stage but thinks it's probably worse to not do it [09:39] fwereade_: updated https://codereview.appspot.com/14387043 [09:39] not just a test update - there shouldn't have been a default set at all [09:40] axw, LGTM assuming it works live ;) [09:40] it does indeed [09:40] thanks [09:40] * axw tests them all together now [09:41] * fwereade_ approves :) [09:46] all good [09:46] well [09:46] on the upside, now I know a bit more about how the machine agent works [09:55] fwereade_: suggestions for a good error message when there's no environment info for an environment? [09:56] fwereade_: i'm thinking of going with "environment does not exist" [09:56] fwereade_: but that's worryingly similar to "environment not found" [09:56] fwereade_: "environment not prepared" is more accurate, but probably confusing to the user [09:56] rogpeppe, I'm kinda leaning towards "is not bootstrapped", but I'm fretting there's some way for that to be wrong [09:56] fwereade_: there is [09:57] fwereade_: because you can do sync-tools before bootstrap [09:57] fwereade_: bootstrapped status is largely orthogonal to prepared status [09:57] fwereade_: except that destroy-environment resets both of them [09:58] rogpeppe, I seem to be unusually dense today -- but if we have no info, and no valid config, how *could* we have boostrapped? [10:00] fwereade_: we could have changed the config after bootstrapping [10:00] fwereade_: "is not bootstrapped" is logically accurate, i suppose [10:01] rogpeppe, is the situation any worse than it would be if you broke the config after bootstrapping with 1.14? [10:01] fwereade_: it's possibly a little more misleading [10:02] fwereade_: saying "is not bootstrapped" kind of implies that the only way to rectify the situation is to bootstrap, but actually sync-tools will do the job too [10:03] rogpeppe, ok, but why sync-tools without a view to a bootstrap? ;) [10:03] fwereade_: i guess my issue comes from the fact that we're saying "is not bootstrapped", when we actually have no idea if the user has bootstrapped or not. [10:04] fwereade_: but as an error message, i think it works ok [10:04] fwereade_: even if it's not *strictly* accurate [10:04] fwereade_: so i think i'll go with it [10:04] rogpeppe, I think they either didn't bootstrap, of they broke their environment in a way we've never been able to fix [10:04] rogpeppe, I say go with it :) [10:05] fwereade_: or they didn't sync-tools :-) [10:05] fwereade_: will do === natefinch-bed is now known as natefinch [10:05] morning all [10:05] morning natefinch [10:06] rogpeppe: fwiw, as long as juju bootstrap fixes "is not bootstrapped" I think that's fine. I much prefer an error that makes it obvious how to fix it, even if it's not 100% accurate. [10:06] natefinch: cool [10:07] rogpeppe: re your comment about panicking: noted, but it's going thru the bot now [10:07] axw: np [10:07] I'll do that next time I touch it [10:08] fwereade_: should I be marking these all against 1.15.1, or is that actually cut and nobody announced it? [10:17] axw, I don't think sinzui is up yet, so I lackinfo [10:17] natefinch, heyhey, is there a problem with that doc branch or can we land it? [10:18] fwereade_: bot was messed up last night. Tim was looking at it when I went to bed. /tmp was full or something [10:18] fwereade_: otherwise, yes, totally ready [10:19] natefinch, ah, great,dimiter cleared that up this morning [10:19] fwereade_: I just poked it again, so the bot will land it [10:21] I'm off, have a nice weekend all [10:26] axw, cheers, and you [10:27] axw, thanks for all your help this week [10:46] rogpeppe, mgz, standup? [10:47] dimitern, fwereade_: https://codereview.appspot.com/14388044 [10:47] dimitern: ta [10:52] oh ffs [11:17] fwereade_: https://codereview.appspot.com/14386044 [11:31] fwereade_, dimitern, mgz: i need a review of the above, please [11:33] rogpeppe, sorry, what's invalid about the info in the first test? [11:34] fwereade_: it hasn't got a state-id [11:34] fwereade_: which the dummy provider adds when preparing [11:34] fwereade_: i'll add a comment [11:34] rogpeppe, cheers [11:35] rogpeppe, another trivial or two, otherwise LGTM [11:38] fwereade_: i'm trying to understand https://codereview.appspot.com/14388043 [11:38] fwereade_: why can't we just set the Location to the req.Host directly [11:38] ? [11:38] fwereade_: i don't see why we have to do all the port mangling [11:40] fwereade_: and why should being able to do a HEAD be predicated on running secure (ie. with a tls.Config) [11:40] ? [11:41] rogpeppe, I'm sorry to say I made a trust call on that one -- please comment on the review. re secure HEAD -- I do not know why we even do anything http-only tbh, but it seemed out of scope === gary_poster|away is now known as gary_poster [12:10] mgz, fwereade_: looks like the bot may be down - i approved this 50 minutes ago and it still hasn't made any progress: https://code.launchpad.net/~rogpeppe/juju-core/440-fix-addressupdater/+merge/189238 [12:35] still no movement on https://code.launchpad.net/~rogpeppe/juju-core/440-fix-addressupdater/+merge/189238 [12:35] * rogpeppe goes to lunch [12:35] mgz: if you were able to investigate the 'bot problem, that would be great... [12:36] rogpeppe: something does seem to be up... [13:06] rogpeppe: answer to the mystery, btw [13:06] mgz: oh yes? [13:06] there was a mongodb process from a test left around, which inherited the filehandle of our flock file [13:07] so, that got left in a locked state, so the cronjob was not obtaining the lock or starting any new work [13:07] there are like, a bunch of ways to make that more robust [13:07] mgz: ah, so it's merrily continuing on its way now? [13:08] I huped the mongod process and things are happy again, your mp is being processed [13:09] mgz: let's hope one of the not-so-intermittent test failures doesn't strike again [13:18] merged! [13:34] natefinch, do you have any docs left to merge? [13:34] fwereade: nope, mine are all in [13:35] natefinch, great, thanks [13:36] natefinch, bug up to date? [13:36] fwereade: oops, nope, I'll go poke it [13:36] natefinch, cheers [13:43] fwereade: do you agree that bootstrap.ConfigureBootstrapMachine should live in provider/common ? [13:45] rogpeppe, probably [13:45] fwereade: given that it's designed to be used as part of provider implementions, which bootstrap.Bootstrap is not [13:46] rogpeppe, wait, no [13:46] rogpeppe, nothing to do with a provider implementation [13:46] fwereade: well, kinda [13:47] rogpeppe, coincidentally called by the local provider [13:47] fwereade: a provider either arranges for jujud bootstrap to be called, or it does it itself [13:47] rogpeppe, I see no good reason not to use jujud bootstrap across the board [13:47] fwereade: yeah, the local provider should probably just exec it [13:48] rogpeppe, pretending that state manipulation is part of a provider implementation will not lead us along a happy path [13:48] fwereade: yeah, hmm [13:48] rogpeppe, it's not in a good place now, though [13:48] fwereade: yeah [13:54] fwereade: so, it sounds like Tim has a solution to the "juju destroys all MaaS nodes" but needs to verify it. So, I presume I don't need to work on that. I can try to finish up the EC2 root disk stuff... as I said in the standup, the constraint works, we're just not getting the value back in status [13:56] natefinch, ok, that's great, I'll sync up with him on sunday night and make sure, but fixing root-disk would be awesome [13:57] natefinch, thanks [13:58] fwereade: cool. Do you have a good process for debugging what's going on with jujud and the agents? I've mostly done work on the client, so not really sure how I'd test out code on the bootstrap node (other than repeatedly destroying/bootstrapping with the new code) [14:00] natefinch, keeping half an eye on debug-log,and meditating upon the infinite, basicaly [14:00] natefinch, but if it's something specific I might be more helpful? [14:00] fwereade, what is this milestone, https://launchpad.net/juju-core/+milestone/dev-docs [14:00] fwereade: heh... mostly just that there's information I expected to be there that isn't there. I guess looking at the code for goamz and seeing if it actually returns the hardware characteristics would help [14:03] natefinch, don't think so [14:04] natefinch, we hope to get instance-type data into simplestreams sometime [14:04] natefinch, but for now the best we can do is use the hardcoded tables [14:05] fwereade: if we allow people to set the disk space, I'd prefer we return no information rather than wrong information. [14:06] natefinch, yeah, I'd be inclined to take the RootDisk info out of instancetype.go [14:06] natefinch, and just always insert the value from the attached ebs volume [14:08] natefinch, might be worth checking with sidnei if he had any clever plans in that direction too [14:08] fwereade: cool, ok [14:35] fwereade: how about folding most of ConfigureBootstrapMachine into agent.InitialStateConfiguration? [14:36] fwereade: (which I'd probably rename to something like InitializeState) [14:38] rogpeppe, sounds reasonable [14:39] fwereade: this came about because i was fiddling with provider/local bootstrap and looking at ConfigureBootstrapMachine, realised that it didn't have a test, then started writing one, then realised things could probably be simpler... [14:40] rogpeppe, I am more than happy to see that stuff tidied up [14:44] fwereade: i don't really like the way that InitialStateConfiguration is written as a free func that only works on a particular type either. It should really be part of the Config interface, but really I think the Config interface should be a concrete struct, although i know tim thinks differently. [14:46] rogpeppe, the cast to *configInternal does look like crack to me [14:52] fwereade: wow, that is total crack [14:56] fwereade: that'll panic if you pass any other implementation of that interface [14:56] natefinch, thankfully there aren't any others, but still [14:58] fwereade: still... I agree, it should be a method on the interface... certainly not a function that someone else can call and cause to panic by implementing some other Config [15:01] fwereade, regarding the comment here: https://codereview.appspot.com/14389043/diff/1/state/state.go#newcode693. Don't we need this function so we can data in the megawatcher? [15:04] mattyw, that's got a *State, so we can get to it -- and I'm a bit twitchy about having different ways to do the same thing in state [15:05] mattyw, I don't think it's a blocker in any way, minor matter of taste [15:09] mattyw, (there are a couple of other similar methods lurking already, that IMO should be in another package and make use of the bits exported from state because that's all they use, but... it's really not a huge deal) [15:11] fwereade, ok, I might leave it like that for now but it's something to meditate on :) [15:12] fwereade, one more question: for this https://codereview.appspot.com/14389043/diff/1/worker/uniter/context.go#newcode145 should we pass it in to HookContext as a parameter to NewHookContext - or work it out inside NewHookContext? [15:12] (I guess passing it in makes it easier to test?) [15:12] mattyw, passing it in feels a bit easier [15:13] fwereade, sure [15:14] fwereade, someone? I see this error running make check from the tarball on saucy and precise: http://pastebin.ubuntu.com/6192615/ [15:14] ick [15:16] sinzui, oh *hell* the dirty sockets have shown up occasionally since forever -- is it consistent? [15:16] sinzui: it's an intermittent failure, try make check again [15:16] looking for bug# [15:16] I have run the test 1 on saucy, 2 on precise, always the same hardware [15:17] * sinzui is running the branch on saucy now [15:24] mgz, I got the same failure again. Can I treat this as an issue local to me. My next step in the release is to build the deb locally to confirm the recipe [15:25] sinzui: it seems worth continuing for the moment [15:25] okay [15:26] mgz, sinzui: agreed, cannot repro [15:31] * sinzui just realised that Lana Del Rey's Dark Paradise has a sound similar to his IRC notification [15:41] mgz, can I set the tools-url to url outside of the cloud? I want to build a stream from my new deb, put it on people.canonical.com, then deploy to aws, hp, etc... [15:42] sinzui: hm, wonder what the best way of testing is these days [15:49] sinzui: so, my old way of doing this doesn't work any more, and I've not seen instructions from ian on exactly what we should be doing instead [15:49] right [15:50] but you *can* generate your own simplestreams bits using the plugins commands and get juju to use those somehow [15:50] I just want to get my confidence a little higher about building all the deb [15:50] I will explore my options with tools-url [16:05] gents, I need to be away now [16:06]