/srv/irclogs.ubuntu.com/2015/10/26/#juju-dev.txt

cheryljwallyworld_: ping?01:13
wallyworld_hey01:13
wallyworld_wot you doing working on a sunday01:13
cheryljheh01:13
cheryljbeing concerned about lxc containers on wily01:14
wallyworld_which bits?01:14
rick_h__cherylj: how does that go?01:14
mupBug #1509747 changed: Intermittent lxc failures on wily <bug-squad> <lxc> <wily> <juju-core:Invalid> <systemd (Ubuntu):New> <https://launchpad.net/bugs/1509747>02:04
mupBug #1509747 opened: Intermittent lxc failures on wily <bug-squad> <lxc> <wily> <juju-core:Invalid> <systemd (Ubuntu):New> <https://launchpad.net/bugs/1509747>02:07
mupBug #1509747 changed: Intermittent lxc failures on wily <bug-squad> <lxc> <wily> <juju-core:Invalid> <systemd (Ubuntu):New> <https://launchpad.net/bugs/1509747>02:10
wallyworldaxw: 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 anyway02:47
wallyworldbecause the bootstrap agent would search for tools and set agent-version accordingly02:47
axwwallyworld: 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:48
mupBug #1509353 changed: local provider service cannot be enabled after disabling <local-provider> <systemd> <juju-core:Won't Fix> <https://launchpad.net/bugs/1509353>02:49
wallyworldto match user expectation02:50
wallyworldif user can see latest version is .2, and server cn't, i think we'd rather log that02:50
wallyworldand allow user to upgrade as required after02:50
wallyworldi dislike the whole auto upgrade thing anyway02:51
wallyworldfor 2.0, we should flip that02:51
wallyworldi guess it's a matter of opinion which way works best02:52
axwwallyworld: 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 sees02:52
wallyworldi can see both sides02:52
axwwallyworld: if we're doing away with it02:52
axwwallyworld: then fine, I can live with this02:52
wallyworldit won't be changed till 2.0, so if there's a real problem with the current approach, i'd need to change that now02:53
axwwallyworld: it's not a problem, I just don't agree with the approach. let's fix the actual problem first though - shipit02:53
wallyworldi think your view is good02:53
wallyworldi did oscillate between the 2 approaches02:54
axwwallyworld: my way means a lot more work for not a lot more gain02:54
wallyworldthat was part of my thnkong02:54
wallyworldok, i'll ship it, it does solve the immediate problem02:55
davecheney... Panic: local error: bad record MAC (PC=0x414706)05:24
davecheneyevery05:24
davecheneygod05:24
davecheneydamn05:24
davecheneyday05:24
axwwallyworld: 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 so05:34
wallyworldok05:35
wallyworldlooking05:35
axwwallyworld: I have coded the image ID parsing, but it would be good not to have to05:35
axwwallyworld: 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=daily05:37
wallyworldaxw: the structured metadata stuff does support streams05:37
wallyworldso we don't lose anything there05:37
axwwallyworld: azure doesn't have a concept of image streams05:37
axwwallyworld: (but I can fake it by parsing the SKU name)05:38
wallyworldi think that sound s ok05:38
wallyworldaxw: 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:39
axwwallyworld: right05:40
wallyworldaxw: my concern is that perhaps the cpc folks want to control the images use05:40
axwwallyworld: query it with a fixed publisher of "Canonical", and offering of "UbuntuServer" (something similar for Windows)05:40
wallyworlddvia simplestreams05:40
wallyworldor are we saying that they would do that via what they publish to azure05:41
axwwallyworld: pretty sure this information is based on images that are provided by CPC, but we'll see what Ben says05:41
wallyworldok05:41
axwfwereade: 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?09:19
rogpeppea small fix to make the recent changes to fslock.NewLock backwardly compatible: https://github.com/juju/utils/pull/16611:09
fwereaderogpeppe, 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 anyway11:30
rogpeppefwereade: in a call11:31
fwereaderogpeppe, np11:31
perrito666wallyworld: anastasiamac axw brt12:00
wallyworldsure12:00
rogpeppefwereade: we really should maintain backward compat when possible.12:04
rogpeppefwereade: also, we *are* using version pinning but this bit us.12:04
fwereaderogpeppe, ok, I imagine you updated for something else and this was a surprise?12:05
rogpeppefwereade: 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 package12:05
rogpeppefwereade: yes12:05
rogpeppefwereade: i don't want to predicate moving our stuff forward on landing the change in juju-core12:06
fwereaderogpeppe, 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
rogpeppefwereade: also, having the default function use wall clock time seems reasonable to me - it's idiomatic and obvious12:07
fwereaderogpeppe, right, but it's also an implicit dependency on global time which has bitten us more times than I care to count12:07
fwereaderogpeppe, NewLockWithClock implies that explicit dependencies are the special case12:08
fwereaderogpeppe, and that's subtly corrosive imo12:08
rogpeppefwereade: it's reasonable to make new functions that do this12:08
rogpeppefwereade: but let's *please* preserve backward compatibility rather than introducing gratuitous breakage of old code12:09
rogpeppefwereade: when reasonablew12:09
rogpeppefwereade: particularly when in non-gopkg packages12:09
rogpeppefwereade: juju-core is not the only consumer of the packages under github.com/juju12:09
fwereaderogpeppe,  right, but that's not gratuitous breakage; it's addressing a real problem, that implicit dependencies hamstring our ability to cleanly use and test code12:11
rogpeppefwereade: you're going to have to change the code anyway12:12
rogpeppefwereade: it's not a problem currently for third party packages currently12:12
rogpeppefwereade: but you're making it one12:13
rogpeppefwereade: doing a search for fslock.NewLock is easy to do12:13
fwereaderogpeppe, I definitely think it should be *easy* to change -- having a func with the old interface, and a pointer to same, seems reasonable12:13
rogpeppefwereade: currently we *cannot* move forward with this backwardly incompatible change12:13
rogpeppefwereade: please can we agree to fix it12:14
fwereaderogpeppe, 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
rogpeppefwereade: the problem is that there is no func with the old signature12:14
rogpeppefwereade: 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 compiles12:15
fwereaderogpeppe, 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 dependencies12:15
rogpeppefwereade: please, for the sake of backward compatibilty. you can mark it as "deprecated" if you really want.12:16
mgz_because we have godeps, I'm fine with api breakage on stuff without versioning for sanity12:16
mgz_we're not breaking the ability to build old juju versions12:17
mgz_and the code wasn't actually around long enough for anyone else to use it12:17
rogpeppemgz_: as it happens, this *is* breaking our ability to compile stuff12:17
mgz_rogpeppe: you have packages not using godeps? I thought all the stuff you had used it?12:17
rogpeppemgz_: no, we use godeps12:18
mgz_so, it's fine, you pin at the older version till you update to use the new api12:18
rogpeppemgz_: 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-core12:18
mgz_sure, that's expected12:18
rogpeppemgz_: 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
mgz_function of how go works and the fact we haven't put enough thought into the apis we share12:19
rogpeppemgz_: there's an easy solution: preserve a compatible API12:19
mgz_rogpeppe: nope, but you can change to use a different constructor12:19
rogpeppemgz_: which is trivial in this case12:19
fwereaderogpeppe, 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 of12:20
mgz_that omits the clock12:20
rogpeppemgz_: no, i can't12:20
rogpeppemgz_: fwereade thinks there should be no such constructor12:20
fwereaderogpeppe, is introducing a new constructor not trivial in this case? it seems that's what the CL does12:20
mgz_he can be pursuaded12:20
mgz_provided it's not the default one12:20
fwereaderogpeppe, no, I said that a convenience constructor is fine; nbut that the NewLock name shoudl be reserved for the right way to use the package12:20
rogpeppefwereade: the CL keeps the old constructor as is12:20
fwereaderogpeppe, yes, that is my problem with iit12:20
rogpeppefwereade: it preserves backwards compatibility12:21
fwereaderogpeppe, with a bad API, yes12:21
rogpeppefwereade: arguably yes, but backward compatibility trumps bad API in this case, i think12:21
rogpeppefwereade: it's just a name12:21
fwereaderogpeppe, names are important12:21
rogpeppefwereade: yes, i agree12:21
mgz_rogpeppe: make the change NewLock (has clock) and NewLockGlobalTime or wtv and it's fine12:22
rogpeppemgz_: that's not possible for us12:22
rogpeppemgz_: because we're not calling NewLock12:22
rogpeppemgz_: it's juju-core that calls NewLock12:22
mgz_it is, you just change the name when you bump the dep12:22
rogpeppemgz_: we can't12:22
mgz_meph, that is a little fun12:22
rogpeppemgz_: because we're dependent on juju-core12:22
rogpeppemgz_: juju-core needs to be changed to use the new function12:22
rogpeppemgz_: but i suspect that's not trivial12:23
mgz_and you can't pin to the right juju-core version because you need something there?12:23
rogpeppemgz_: there is no right juju-core version12:23
mgz_rogpeppe: which juju-core are you basing from?12:23
mgz_master?12:23
rogpeppemgz_: latest master12:23
mgz_okay, so we can still fix this12:23
mgz_utils gains a constructor12:23
mgz_master of juju/juju picks that up and renames callers12:24
mgz_you then pin at that landed master version12:24
rogpeppemgz_: i guess we could land a change in juju master to just globally substiture NewTimer to add clock.WallClock as an argument.12:24
rogpeppemgz_: but that's avoiding the whole reason for doing this12:24
mgz_this is true.12:24
fwereaderogpeppe, 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:25
rogpeppefwereade: 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:26
rogpeppefwereade: i see an argument for being able to fake it12:27
mgz_I feel the monad rising up12:27
fwereaderogpeppe, 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 aggregate12:27
rogpeppefwereade: but i'm not sure about the capability to have several kinds of clock extant in the same program12:27
fwereademgz_, lol12:27
fwereaderogpeppe, indeed: ideally, you'll have a single clock configured at the top level and delivered wherever it needs to go12:28
rogpeppefwereade: isn't that just because it's not possible to fake time.Time in general?12:28
rogpeppefwereade: if everyone used juju/clock instead (which provided a fakable time), wouldn't that be good enough?12:28
fwereaderogpeppe, 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 imo12:29
fwereaderogpeppe, 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 explicit12:30
fwereaderogpeppe, and that leads towards heavy constructors, which aren't necessarily so pretty12:30
mgz_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 about12:30
rogpeppefwereade: for most things, i tend to agree, but clock does seem pretty global to me. although testing clock divergence is interesting.12:30
fwereaderogpeppe, 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 maintainer12:31
rogpeppefwereade: i wish that the mechanism used by the Go playground was generally accessible12:33
fwereaderogpeppe, that'd mitigate, yes, but I'm on a pretty strong all-global-mutable-state-is-bad kick at the moment12:34
fwereaderogpeppe, 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 it12:35
rogpeppefwereade: in fact, you probably wouldn't want that, as it would preclude actual real timeouts in tests12:36
fwereaderogpeppe, ha, good point12:36
fwereadewell12:36
rogpeppefwereade: but the idea of a sandboxed runtime started for each test is an interesting one12:36
fwereaderogpeppe, yeah, so long as you had the watchdog timer outside it I think it cold work quite nicely12:37
rogpeppefwereade: well, the watchdog timer *is* outside it12:37
fwereaderogpeppe, but you'd want access to that for the bits that really do involve timeouts12:37
fwereaderogpeppe, so, yeah, it's fiddly12:37
rogpeppefwereade: 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:39
rogpeppefwereade: because we are not developing juju-core and really don't want our moving forward to be predicated on changes there12:41
rogpeppefwereade: think of it like this: the API has been "wrong" for >2 years now. another week or so surely isn't too bad.12:44
fwereadedooferlad, do you have the bandwidth to follow up on that; and, rogpeppe, to absorb that change when it does come?12:57
rogpeppefwereade: we don't have a problem with absorbing the change 'cos we're not actually using the fslock API12:57
rogpeppefwereade: (only indirectly)12:58
rogpeppefwereade: going for lunch now12:59
fwereaderogpeppe, ok, cool -- and dooferlad, does that work for you? I presume you had a actually-use-in-juju-core change coming up anyway?12:59
dooferladfwereade: yes, once my changes land I will be happy to fix the integration with Juju core13:07
fwereadedooferlad, rogpeppe: awesome, ty both13:07
dooferladfwereade, 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:18
rogpeppedooferlad: tbh i don't really know why we're using file-creation-based locking anyway when we could use flock13:20
rogpeppefwereade: are we planning on getting rid of the global logger instances too?13:22
dooferladrogpeppe: 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
fwereaderogpeppe, I would like to, yeah, but it's not so near the top of my list13:22
fwereaderogpeppe, they're yucky but not generally actively painful IME13:23
fwereaderogpeppe, or at least not so often13:23
rogpeppedooferlad: i'm sure there's some equivalent on all the platforms we use13:24
fwereaderogpeppe, whereas implicit dependencies on wall-clock time are an ongoing thorn in our side13:24
mupBug #1506666 changed: juju bootstrap fails in virtualbox <local-provider> <network> <virtualbox> <wily> <juju-core:Invalid> <https://launchpad.net/bugs/1506666>13:24
rogpeppedooferlad: unix has had flock or fcntl(F_SETLK) for a long time13:24
rogpeppedooferlad: and windows locks files by default anyway when they're open13:25
rogpeppedooferlad: it would certainly be more efficient to use the OS file lock primitives13:25
dooferladrogpeppe: 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:26
rogpeppedooferlad: yeah, sorry, it was just a random aside. i don't like it but that is indeed what we've got13:27
dooferladrogpeppe: no problem. Sore topic.13:27
mupBug #1506666 opened: juju bootstrap fails in virtualbox <local-provider> <network> <virtualbox> <wily> <juju-core:Invalid> <https://launchpad.net/bugs/1506666>13:27
mupBug #1506666 changed: juju bootstrap fails in virtualbox <local-provider> <network> <virtualbox> <wily> <juju-core:Invalid> <https://launchpad.net/bugs/1506666>13:30
mupBug #1506666 opened: juju bootstrap fails in virtualbox <local-provider> <network> <virtualbox> <wily> <juju-core:Invalid> <https://launchpad.net/bugs/1506666>13:33
mupBug #1506666 changed: juju bootstrap fails in virtualbox <local-provider> <network> <virtualbox> <wily> <juju-core:Invalid> <https://launchpad.net/bugs/1506666>13:48
katco`wwitzel3: ericsnow: natefinch: standup?14:06
natefinchkatco`: we're there14:06
* katco` mutters at computer14:06
katco`fwereade: ping14:22
=== katco` is now known as katco
fwereadekatco, pong14:23
cheryljfrobware: Can you make sure that someone picks up bug 1483879 as part of sapphire's bug squad work this iteration?14:23
mupBug #1483879: MAAS provider: terminate-machine --force or destroy-environment don't DHCP release container IPs <bug-squad> <destroy-machine> <landscape> <maas-provider> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1483879>14:23
katcofwereade: can you hop in moonstone rq? https://plus.google.com/hangouts/_/canonical.com/moonstone?authuser=114:23
frobwarecherylj, ack. I would like to sync up today if you have time.14:33
cheryljfrobware: I'm free for the next hour14:38
frobwarecherylj, OK can you jump on the following https://plus.google.com/hangouts/_/canonical.com/juju-sapphire14:40
cheryljfrobware: yes, let me find my headset.14:40
cheryljfrobware: I'm there14:43
rogpeppeanyone know why we're using github.com/gabriel-samfira/sys rather than the repo it's cloned from (golang.org/x/sys) ?14:43
ericsnowrogpeppe: Go 1.2 compatibility14:44
rogpeppeericsnow: oh, marvellous14:44
ericsnowrogpeppe: yep :(14:44
rogpeppeericsnow: couldn't we at least make our own fork rather than copying some random guy's ?14:45
ericsnowrogpeppe: gsamfira isn't exactly a "random guy" (he's one of the cloudbase folks)14:45
ericsnowrogpeppe: but I doubt anyone would object to a fork under the juju org14:45
rogpeppeericsnow: ok, i see14:46
mupBug #1497301 changed: mongodb3  SASL authentication failure <ci> <mongodb> <regression> <unit-tests> <juju-core:Invalid> <https://launchpad.net/bugs/1497301>15:07
mupBug #1510129 opened: error: cannot re-bootstrap environment: cannot bootstrap new instance: Juju cannot bootstrap because no tools are available for your environment. <backup-restore> <ci> <intermittent-failure> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1510129>15:07
mupBug #1510132 opened: redefinition of ‘noMethods$MarshalYAML$hash’ <ci> <testing> <juju-core:New> <juju-core model-migration:Triaged> <https://launchpad.net/bugs/1510132>15:07
mupBug #1510133 opened: juju's ConnSuite should not start a UnitAssigner worker <tech-debt> <juju-core:New> <https://launchpad.net/bugs/1510133>15:07
rogpeppemgz_: 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:13
rogpeppemgz_: also, should feature branches be deleted after they've been merged?15:14
mgz_rogpeppe: yeah, we've been futzing with priorities and trying to get 1.24/1.25 done last week meant master has been rather neglected15:27
mgz_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 anyway15:27
perrito666bbl outside lunch15:46
fwereadetasdomas, have you run the meter-status tests with -race? I think the code field, at least, is problematic15:50
dooferladdimitern: hangout?16:03
dimiterndooferlad, omw16:03
ericsnowwwitzel3: ready16:34
wwitzel3ericsnow: ok, just finishing lunch16:49
ericsnowwwitzel3: np16:49
natefinchfwereade: if I'm just copying  uniter's SetAgentStatus code... why am I not just calling the uniter's version?16:53
fwereadenatefinch, the functionality is the same but the auth certainly shouldn't be16:53
fwereadenatefinch, different facades responsible for different auth16:54
natefinchfwereade: hmm true....16:54
fwereadenatefinch, but calling through to the same underlying implementation because they're doing the same thing16:54
natefinchfwereade: 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:57
fwereadenatefinch, 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 package16:58
natefinchfwereade: I'll put it in setstatus.go.... time and energy for this bug are long gone, unfortunately.17:01
fwereadenatefinch, sgtm17:04
=== jam2 is now known as jam1
natefinchfwereade: 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:14
fwereadelook for IsCodeNotFound17:15
fwereadeif 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 ;p17:15
fwereadethat was not expressed appropriately17:15
fwereadeI am entirely aware you are a wonderful person already ;p17:16
natefinchfwereade: haha, perfectly appropriately... .and I had been thinking of doing tha17:16
natefinchlol17:16
* fwereade eod, might pass by later17:17
mgz_how do I find the specs and shizzle for this cycle?17:29
mgz_ah, alexisb linked them all in her summary doc, that'll do17:30
natefinchman our API comments are terrible19:15
natefinchSetEntityStatus 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 ofr19:16
natefinchfor19:16
natefinchkatco: got the unit status setting code working. Needs tests, though, which will take a bit.19:57
katconatefinch: yay :) get those tests written! :)19:57
thumpermramm: hey, we are going to need to change our call times :)20:25
thumpermramm: since nz is now in summer time20:25
frobwarecherylj, ping - 1496972, should that not be for 1.24 as well?21:21
cheryljfrobware: 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:28
cheryljmake sure they're not committed to 1.24 or anything21:29
thumpercherylj: is http://reviews.vapour.ws/r/2998/diff/# a forward port or did this not land yet?22:03
cheryljthumper: the 1.26 revision addressing fwereade's comments had not landed yet.  This is it.22:03
thumpercherylj: what's the difference?22:04
cheryljthumper: the biggest difference is that the retry strategy is generated by the provisioner, rather than the lxc code22:05
thumperk22:05
cheryljthumper: the original review is here:  http://reviews.vapour.ws/r/2761/22:06
cheryljif you want it for reference22:06
mattywdavechen1y, are you around?22:29
perrito666wallyworld_: axw anastasiamac I might be a bit late, suddenly I have no sound from the browser23:05
wallyworld_\o/23:05
perrito666software makes me really miserable23:05
anastasiamac:(23:06
anastasiamacperrito666: i *think* i know what u mean :P23:06
perrito666ready, found an alternate solution23:13
axwthumper: do machine provisioners run concurrently for each hosted env?23:55
axwthumper: and firewaller23:56

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!