[01:13] wallyworld_: ping? [01:13] hey [01:13] wot you doing working on a sunday [01:13] heh [01:14] being concerned about lxc containers on wily [01:14] which bits? [01:14] cherylj: how does that go? [02:04] Bug #1509747 changed: Intermittent lxc failures on wily

[02:07] Bug #1509747 opened: Intermittent lxc failures on wily

[02:10] Bug #1509747 changed: Intermittent lxc failures on wily

[02:47] axw: that the client might see tools the bootstrap agent can't see is the reason for the patch; the approach allows the client to be opinionated about what it asks for based on user input, but provides a safety net that the agent can reject that if the tools are not available server side. if the bootstrap agent were to use a flag to determne if newer tools were required, it would essentially be the same code as written now anyway [02:47] because the bootstrap agent would search for tools and set agent-version accordingly [02:48] wallyworld: the agent says "bootstrap, then upgrade to to the latest patch version". "latest patch version" may means different things to the CLI and the bootstrap agent. why fail to upgrade to .1 just because .2 isn't there? [02:49] Bug #1509353 changed: local provider service cannot be enabled after disabling

[02:50] to match user expectation [02:50] if user can see latest version is .2, and server cn't, i think we'd rather log that [02:50] and allow user to upgrade as required after [02:51] i dislike the whole auto upgrade thing anyway [02:51] for 2.0, we should flip that [02:52] i guess it's a matter of opinion which way works best [02:52] wallyworld: what's meant to happen is that it upgrades to the latest available patch version. we're changing the meaning of "latest available" from what the client sees to what the bootstrap agent sees [02:52] i can see both sides [02:52] wallyworld: if we're doing away with it [02:52] wallyworld: then fine, I can live with this [02:53] it won't be changed till 2.0, so if there's a real problem with the current approach, i'd need to change that now [02:53] wallyworld: it's not a problem, I just don't agree with the approach. let's fix the actual problem first though - shipit [02:53] i think your view is good [02:54] i did oscillate between the 2 approaches [02:54] wallyworld: my way means a lot more work for not a lot more gain [02:54] that was part of my thnkong [02:55] ok, i'll ship it, it does solve the immediate problem [05:24] ... Panic: local error: bad record MAC (PC=0x414706) [05:24] every [05:24] god [05:24] damn [05:24] day [05:34] wallyworld: just responded to your email on simplestreams. let me know ify ou think that's a reasonable limitation to live with, and I'll make it so [05:35] ok [05:35] looking [05:35] wallyworld: I have coded the image ID parsing, but it would be good not to have to [05:37] wallyworld: actually I could do something hackish with the stream, and exclude the SKUs with "DAILY" in the name if stream=release, use those ones only if stream=daily [05:37] axw: the structured metadata stuff does support streams [05:37] so we don't lose anything there [05:37] wallyworld: azure doesn't have a concept of image streams [05:38] wallyworld: (but I can fake it by parsing the SKU name) [05:38] i think that sound s ok [05:39] axw: so i think for option a), the suggestion is to modify azure's findImage() to not query juju's structured metadata collection, but query the provider apis instead? [05:40] wallyworld: right [05:40] axw: my concern is that perhaps the cpc folks want to control the images use [05:40] wallyworld: query it with a fixed publisher of "Canonical", and offering of "UbuntuServer" (something similar for Windows) [05:40] dvia simplestreams [05:41] or are we saying that they would do that via what they publish to azure [05:41] wallyworld: pretty sure this information is based on images that are provided by CPC, but we'll see what Ben says [05:41] ok [09:19] fwereade: I see you're looking at http://reviews.vapour.ws/r/2958/, can you please also take another look at http://reviews.vapour.ws/r/2935/ later? [11:09] a small fix to make the recent changes to fslock.NewLock backwardly compatible: https://github.com/juju/utils/pull/166 [11:30] rogpeppe, dammit, I sort of see the backward compatibility concerns, but... (1) I really do not want to encourage people to use wall clocks and (2) anyone using a package without some sort of pinning is asking for trouble anyway [11:31] fwereade: in a call [11:31] rogpeppe, np [12:00] wallyworld: anastasiamac axw brt [12:00] sure [12:04] fwereade: we really should maintain backward compat when possible. [12:04] fwereade: also, we *are* using version pinning but this bit us. [12:05] rogpeppe, ok, I imagine you updated for something else and this was a surprise? [12:05] fwereade: because pinning to the latest version of juju (which hasn't yet been updated to use latest utils changes) but we need a more recent change in another utils package [12:05] fwereade: yes [12:06] fwereade: i don't want to predicate moving our stuff forward on landing the change in juju-core [12:07] rogpeppe, I must say I'd still prefer to go for a doc note saying "if you must, you can use the NewClockWithGlobalTime func which uses the old interface"? [12:07] fwereade: also, having the default function use wall clock time seems reasonable to me - it's idiomatic and obvious [12:07] rogpeppe, right, but it's also an implicit dependency on global time which has bitten us more times than I care to count [12:08] rogpeppe, NewLockWithClock implies that explicit dependencies are the special case [12:08] rogpeppe, and that's subtly corrosive imo [12:08] fwereade: it's reasonable to make new functions that do this [12:09] fwereade: but let's *please* preserve backward compatibility rather than introducing gratuitous breakage of old code [12:09] fwereade: when reasonablew [12:09] fwereade: particularly when in non-gopkg packages [12:09] fwereade: juju-core is not the only consumer of the packages under github.com/juju [12:11] rogpeppe, right, but that's not gratuitous breakage; it's addressing a real problem, that implicit dependencies hamstring our ability to cleanly use and test code [12:12] fwereade: you're going to have to change the code anyway [12:12] fwereade: it's not a problem currently for third party packages currently [12:13] fwereade: but you're making it one [12:13] fwereade: doing a search for fslock.NewLock is easy to do [12:13] rogpeppe, I definitely think it should be *easy* to change -- having a func with the old interface, and a pointer to same, seems reasonable [12:13] fwereade: currently we *cannot* move forward with this backwardly incompatible change [12:14] fwereade: please can we agree to fix it [12:14] rogpeppe, so, is the problem that there is no func with the old signature; or that a global search-and--replace is an excessive burden? [12:14] fwereade: the problem is that there is no func with the old signature [12:15] fwereade: so there is no version of juju-core we can pin to that both provides us with the new functionality we need in utils and compiles [12:15] rogpeppe, I would happily support the introduction of a func with that signature, but I can't make peace with the obvious default constructor being the one with implicit dependencies [12:16] fwereade: please, for the sake of backward compatibilty. you can mark it as "deprecated" if you really want. [12:16] because we have godeps, I'm fine with api breakage on stuff without versioning for sanity [12:17] we're not breaking the ability to build old juju versions [12:17] and the code wasn't actually around long enough for anyone else to use it [12:17] mgz_: as it happens, this *is* breaking our ability to compile stuff [12:17] rogpeppe: you have packages not using godeps? I thought all the stuff you had used it? [12:18] mgz_: no, we use godeps [12:18] so, it's fine, you pin at the older version till you update to use the new api [12:18] mgz_: but we've landed a new feature in a utils package, but we can't use it because the latest version of utils is incompatible with all versions of juju-core [12:18] sure, that's expected [12:19] mgz_: so you're saying we can't move forward with our stuff until all the clock dependency stuff is implemented in juju-core? [12:19] function of how go works and the fact we haven't put enough thought into the apis we share [12:19] mgz_: there's an easy solution: preserve a compatible API [12:19] rogpeppe: nope, but you can change to use a different constructor [12:19] mgz_: which is trivial in this case [12:20] rogpeppe, I agree we should have kept a convenience func around, but I don't think it's sensible to keep the API pinned to the first version we thought of [12:20] that omits the clock [12:20] mgz_: no, i can't [12:20] mgz_: fwereade thinks there should be no such constructor [12:20] rogpeppe, is introducing a new constructor not trivial in this case? it seems that's what the CL does [12:20] he can be pursuaded [12:20] provided it's not the default one [12:20] rogpeppe, no, I said that a convenience constructor is fine; nbut that the NewLock name shoudl be reserved for the right way to use the package [12:20] fwereade: the CL keeps the old constructor as is [12:20] rogpeppe, yes, that is my problem with iit [12:21] fwereade: it preserves backwards compatibility [12:21] rogpeppe, with a bad API, yes [12:21] fwereade: arguably yes, but backward compatibility trumps bad API in this case, i think [12:21] fwereade: it's just a name [12:21] rogpeppe, names are important [12:21] fwereade: yes, i agree [12:22] rogpeppe: make the change NewLock (has clock) and NewLockGlobalTime or wtv and it's fine [12:22] mgz_: that's not possible for us [12:22] mgz_: because we're not calling NewLock [12:22] mgz_: it's juju-core that calls NewLock [12:22] it is, you just change the name when you bump the dep [12:22] mgz_: we can't [12:22] meph, that is a little fun [12:22] mgz_: because we're dependent on juju-core [12:22] mgz_: juju-core needs to be changed to use the new function [12:23] mgz_: but i suspect that's not trivial [12:23] and you can't pin to the right juju-core version because you need something there? [12:23] mgz_: there is no right juju-core version [12:23] rogpeppe: which juju-core are you basing from? [12:23] master? [12:23] mgz_: latest master [12:23] okay, so we can still fix this [12:23] utils gains a constructor [12:24] master of juju/juju picks that up and renames callers [12:24] you then pin at that landed master version [12:24] mgz_: i guess we could land a change in juju master to just globally substiture NewTimer to add clock.WallClock as an argument. [12:24] mgz_: but that's avoiding the whole reason for doing this [12:24] this is true. [12:25] rogpeppe, mgz, at least it's moving the config one step out towards the edges, which is worthwhile in itself I think? small step but positive? [12:26] fwereade: tbh i'm not entirely convinced by passing the clock as an argument to everything anyway, because isn't it really something that's fundamentally global? [12:27] fwereade: i see an argument for being able to fake it [12:27] I feel the monad rising up [12:27] rogpeppe, it's really not -- it may be convenient in one situation, but the pain of depending on wall-clock time in tests is fricking devastating in aggregate [12:27] fwereade: but i'm not sure about the capability to have several kinds of clock extant in the same program [12:27] mgz_, lol [12:28] rogpeppe, indeed: ideally, you'll have a single clock configured at the top level and delivered wherever it needs to go [12:28] fwereade: isn't that just because it's not possible to fake time.Time in general? [12:28] fwereade: if everyone used juju/clock instead (which provided a fakable time), wouldn't that be good enough? [12:29] rogpeppe, well, (1), I do have use cases where it's good to know what happens when clocks diverge; and (2) if the clock can't be faked without poking into globals, it's not fakeable enough imo [12:30] rogpeppe, I've ended up deciding that the urge to patch is basically always wrong -- it's just working around having made implicit a dependency that ought to be explicit [12:30] rogpeppe, and that leads towards heavy constructors, which aren't necessarily so pretty [12:30] well, the issue is more that time can mean several things and code doesn't have a good mechanism for saying what it actually cares about [12:30] fwereade: for most things, i tend to agree, but clock does seem pretty global to me. although testing clock divergence is interesting. [12:31] rogpeppe, but are still better than the alternative -- in which you have just as many dependencies but they're hidden, and waiting to trip up the unwary maintainer [12:33] fwereade: i wish that the mechanism used by the Go playground was generally accessible [12:34] rogpeppe, that'd mitigate, yes, but I'm on a pretty strong all-global-mutable-state-is-bad kick at the moment [12:35] rogpeppe, maybe it'd even mitigate enough not to matter -- if I could create a complete sandboxed runtime I wouldn't be so worried about the globals inside it [12:36] fwereade: in fact, you probably wouldn't want that, as it would preclude actual real timeouts in tests [12:36] rogpeppe, ha, good point [12:36] well [12:36] fwereade: but the idea of a sandboxed runtime started for each test is an interesting one [12:37] rogpeppe, yeah, so long as you had the watchdog timer outside it I think it cold work quite nicely [12:37] fwereade: well, the watchdog timer *is* outside it [12:37] rogpeppe, but you'd want access to that for the bits that really do involve timeouts [12:37] rogpeppe, so, yeah, it's fiddly [12:39] fwereade: can we land my change (to preserve backward compatibility) so that we can at least move forward without needing to update juju-core, until juju-core is at least ready to use the new API, at which point the names can be changed? [12:41] fwereade: because we are not developing juju-core and really don't want our moving forward to be predicated on changes there [12:44] fwereade: think of it like this: the API has been "wrong" for >2 years now. another week or so surely isn't too bad. [12:57] dooferlad, do you have the bandwidth to follow up on that; and, rogpeppe, to absorb that change when it does come? [12:57] fwereade: we don't have a problem with absorbing the change 'cos we're not actually using the fslock API [12:58] fwereade: (only indirectly) [12:59] fwereade: going for lunch now [12:59] rogpeppe, ok, cool -- and dooferlad, does that work for you? I presume you had a actually-use-in-juju-core change coming up anyway? [13:07] fwereade: yes, once my changes land I will be happy to fix the integration with Juju core [13:07] dooferlad, rogpeppe: awesome, ty both [13:18] fwereade, rogpeppe: I am in part stuck until http://reviews.vapour.ws/r/2908/ lands, which is related, so if wise heads could take a look that would be delightful. Once that lands in utils I can change the function sigs in juju-core to use an injected time and we will all be happy. [13:20] dooferlad: tbh i don't really know why we're using file-creation-based locking anyway when we could use flock [13:22] fwereade: are we planning on getting rid of the global logger instances too? [13:22] rogpeppe: we started with file based locking, but if a lock wasn't released before the process holding it went away we got in a pickle. This happend a lot when rebooting machines during tests. This is attempting to have a way of automatically breaking stale locks. Flock is linux only. [13:22] rogpeppe, I would like to, yeah, but it's not so near the top of my list [13:23] rogpeppe, they're yucky but not generally actively painful IME [13:23] rogpeppe, or at least not so often [13:24] dooferlad: i'm sure there's some equivalent on all the platforms we use [13:24] rogpeppe, whereas implicit dependencies on wall-clock time are an ongoing thorn in our side [13:24] Bug #1506666 changed: juju bootstrap fails in virtualbox

[13:24] dooferlad: unix has had flock or fcntl(F_SETLK) for a long time [13:25] dooferlad: and windows locks files by default anyway when they're open [13:25] dooferlad: it would certainly be more efficient to use the OS file lock primitives [13:26] rogpeppe: I don't know about the Windows side of things. I was trying to modify what we are already using to be more useful. I dislike using file locks, but that is what we currently have. [13:27] dooferlad: yeah, sorry, it was just a random aside. i don't like it but that is indeed what we've got [13:27] rogpeppe: no problem. Sore topic. [13:27] Bug #1506666 opened: juju bootstrap fails in virtualbox

[13:30] Bug #1506666 changed: juju bootstrap fails in virtualbox

[13:33] Bug #1506666 opened: juju bootstrap fails in virtualbox

[13:48] Bug #1506666 changed: juju bootstrap fails in virtualbox

[14:06] wwitzel3: ericsnow: natefinch: standup? [14:06] katco`: we're there [14:06] * katco` mutters at computer [14:22] fwereade: ping === katco` is now known as katco [14:23] katco, pong [14:23] frobware: Can you make sure that someone picks up bug 1483879 as part of sapphire's bug squad work this iteration? [14:23] Bug #1483879: MAAS provider: terminate-machine --force or destroy-environment don't DHCP release container IPs

[14:23] fwereade: can you hop in moonstone rq? https://plus.google.com/hangouts/_/canonical.com/moonstone?authuser=1 [14:33] cherylj, ack. I would like to sync up today if you have time. [14:38] frobware: I'm free for the next hour [14:40] cherylj, OK can you jump on the following https://plus.google.com/hangouts/_/canonical.com/juju-sapphire [14:40] frobware: yes, let me find my headset. [14:43] frobware: I'm there [14:43] anyone know why we're using github.com/gabriel-samfira/sys rather than the repo it's cloned from (golang.org/x/sys) ? [14:44] rogpeppe: Go 1.2 compatibility [14:44] ericsnow: oh, marvellous [14:44] rogpeppe: yep :( [14:45] ericsnow: couldn't we at least make our own fork rather than copying some random guy's ? [14:45] rogpeppe: gsamfira isn't exactly a "random guy" (he's one of the cloudbase folks) [14:45] rogpeppe: but I doubt anyone would object to a fork under the juju org [14:46] ericsnow: ok, i see [15:07] Bug #1497301 changed: mongodb3 SASL authentication failure

[15:07] Bug #1510129 opened: error: cannot re-bootstrap environment: cannot bootstrap new instance: Juju cannot bootstrap because no tools are available for your environment.

[15:07] Bug #1510132 opened: redefinition of ‘noMethods$MarshalYAML$hash’

[15:07] Bug #1510133 opened: juju's ConnSuite should not start a UnitAssigner worker

[15:13] mgz_: looks like release testing hasn't run on master for a week now. it's making me nervous, particularly with the big chicago-cubs push recently. any chance we could prioritise it? [15:14] mgz_: also, should feature branches be deleted after they've been merged? [15:27] rogpeppe: yeah, we've been futzing with priorities and trying to get 1.24/1.25 done last week meant master has been rather neglected [15:27] feature branches can be deleted after merge, I've not bothered so far as github has good interface for showing what's in and what's not yet anyway [15:46] bbl outside lunch [15:50] tasdomas, have you run the meter-status tests with -race? I think the code field, at least, is problematic [16:03] dimitern: hangout? [16:03] dooferlad, omw [16:34] wwitzel3: ready [16:49] ericsnow: ok, just finishing lunch [16:49] wwitzel3: np [16:53] fwereade: if I'm just copying uniter's SetAgentStatus code... why am I not just calling the uniter's version? [16:53] natefinch, the functionality is the same but the auth certainly shouldn't be [16:54] natefinch, different facades responsible for different auth [16:54] fwereade: hmm true.... [16:54] natefinch, but calling through to the same underlying implementation because they're doing the same thing [16:57] fwereade: ok. I can live with that. There's only a small bit of logic in the unitAgentFinder that is shared.... got an idea of where I could move that so both implementations could share it? [16:58] natefinch, I guess a subpackage of apiserver/common, ideally, but that'd really want to drag the status code in as well... so, I guess, in common/setstatus.go, unless you have time/energy to extract a package [17:01] fwereade: I'll put it in setstatus.go.... time and energy for this bug are long gone, unfortunately. [17:04] natefinch, sgtm === jam2 is now known as jam1 [17:14] fwereade: is there a non-terrible way to figure out if an error returned by the API is a notfound error? Or if not, has someone already written the terrible code that I can reuse? [17:15] look for IsCodeNotFound [17:15] if you were a wonderful person you'd translate that back to a NotFoundError on the way out of the api client code but nobody else ever does that ;p [17:15] that was not expressed appropriately [17:16] I am entirely aware you are a wonderful person already ;p [17:16] fwereade: haha, perfectly appropriately... .and I had been thinking of doing tha [17:16] lol [17:17] * fwereade eod, might pass by later [17:29] how do I find the specs and shizzle for this cycle? [17:30] ah, alexisb linked them all in her summary doc, that'll do [19:15] man our API comments are terrible [19:16] SetEntityStatus take a Status - which is a string, an Info - which is a string, and Data - which is a map[string]interface.... and no description of what each of those things are actually ofr [19:16] for [19:57] katco: got the unit status setting code working. Needs tests, though, which will take a bit. [19:57] natefinch: yay :) get those tests written! :) [20:25] mramm: hey, we are going to need to change our call times :) [20:25] mramm: since nz is now in summer time [21:21] cherylj, ping - 1496972, should that not be for 1.24 as well? [21:28] frobware: I targeted it to 1.25.1 as we're hoping to not do 1.24.8. But yeah, I should check with the guys that brought it up in the cross team call/ [21:29] make sure they're not committed to 1.24 or anything [22:03] cherylj: is http://reviews.vapour.ws/r/2998/diff/# a forward port or did this not land yet? [22:03] thumper: the 1.26 revision addressing fwereade's comments had not landed yet. This is it. [22:04] cherylj: what's the difference? [22:05] thumper: the biggest difference is that the retry strategy is generated by the provisioner, rather than the lxc code [22:05] k [22:06] thumper: the original review is here: http://reviews.vapour.ws/r/2761/ [22:06] if you want it for reference [22:29] davechen1y, are you around? [23:05] wallyworld_: axw anastasiamac I might be a bit late, suddenly I have no sound from the browser [23:05] \o/ [23:05] software makes me really miserable [23:06] :( [23:06] perrito666: i *think* i know what u mean :P [23:13] ready, found an alternate solution [23:55] thumper: do machine provisioners run concurrently for each hosted env? [23:56] thumper: and firewaller