perrito666katco: how optional am I on the second standup?00:01
anastasiamacperrito666: it's almost philosophical - what variations of optional there are? hard optional? soft optional? :D00:03
anastasiamacperrito666: disclaimer:  this question ^^ does not imply ur optionality00:03
perrito666anastasiamac: there is a whole range between "we cant live if living is without you" and  "I dont ever want so see you again"00:05
perrito666(I had to google for the second song, there aren't as many hate you songs as one would expect)00:05
anastasiamacperrito666: really, i was told swift covers a lot of hate ranges00:06
perrito666anastasiamac: the thing is, that is very close to my bike time and I might not make it everyday00:07
anastasiamacperrito666: ack. i have school drop-off at that time too, so cannot do either :/00:08
wallyworldmenn0: thanks for review, i've updated pr00:11
menn0wallyworld: for some reason RB isn't showing any changes between diffs 1 and 200:11
menn0wallyworld: but I trust you, so ship it00:11
wallyworldhmm, ok, ty, i double check00:11
menn0wallyworld: it says there's files changed but when I what to see the diffs there's nothing00:12
menn0looks like a RB problem00:12
* perrito666 sends the kind of mail that makes someone hate you00:13
wallyworldmenn0: i just checked github and the commit it there00:13
wallyworldso wtf rb00:13
* menn0 looks quickly at the changes on GH00:13
* wallyworld waits in anticipation00:14
menn0wallyworld: looks good! my ship it stands :)00:14
wallyworldyay, tyvm00:14
wallyworldanastasiamac: hey, i commented on the pr, sorry it needs rework00:23
anastasiamacwallyworld: i disagree with ur stmt00:23
anastasiamacwallyworld: quick hangout?00:24
mupBug #1546348 opened: cannot use or destroy controller after bootstrap <azure-provider> <bootstrap> <ci> <ec2-provider> <gce-provider> <joyent-provider> <kill-controller>00:25
mup<openstack-provider> <regression> <status> <juju-core:New> <juju-core cloud-credentials:Triaged> <https://launchpad.net/bugs/1546348>00:25
mupBug #1546350 opened: All juju models tagged with "local" <azure-provider> <ec2-provider> <gce-provider> <joyent-provider> <openstack-provider> <juju-core:New> <juju-core cloud-credentials:Triaged> <https://launchpad.net/bugs/1546350>00:25
perrito666state tests take a bit too long00:36
perrito666someone thought this was a useful test failure error:00:40
perrito666Error: entity contents mismatch; same length 100:40
anastasiamacperrito666: juju deals with paradoxes :D00:41
axwwallyworld: I think the CI issue is due to the change from <controller> -> local.<controller>00:44
wallyworldaxw: that sounds like it's Ci scripts not juju00:45
axwwallyworld: model "aws-deploy-trusty-amd64" not found    <-- that'd be because it's called local.aws-deploy-trusty-amd6400:45
wallyworldaxw: that's the model though not the controller00:45
axwwallyworld: yeah, the admin model is currently called the same as the controller00:46
wallyworldaxw: ah, ok, so when we create the admin model,  we need to strip local.00:46
axwwallyworld: that's going to cause problems, due to code expecting controller==model00:46
axwwallyworld: (without the branch I'm working on)00:46
wallyworldaxw: so we need to get your current branch landed i guess00:47
axwwallyworld: yeah, I think so.00:47
axwwallyworld: in the mean time, CI could prefix with local.00:47
axwnot sure how much effort that'd take00:47
wallyworldok, i'll let the qa folks know. i don't think they'd be up for changing scripts now00:47
axwwallyworld: they'll need to change them to expect the model name to be "admin" anywya, in case that's not obvious00:56
axwunless we change it to be the non-prefixed controller name as an intermediate step00:56
wallyworldaxw: i'm discussing with sinzui in #juju now00:57
=== ses is now known as Guest63483
blahdeblahAnyone able to explain to me why juju does what it does to /root/.ssh/authorized_keys, and what I can do to fit in with what it does whilst still enabling what I want, which is that a charm needs to be able to write working entries in there.04:00
blahdeblahThere should have been a ? somewhere in that line.04:00
natefinchdoes anyone know how to debug the uniter tests?  The failures basically read like "Here's a big struct vaguely describing what the test is... oh something failed somewhere"04:18
bradmanyone here know about the multi user stuff?  say we were to run it on top of an openstack cloud, we would only need the top env to be deployed with juju 2.0, right?  the underlying cloud could be a stable juju, say 1.25.3?04:20
natefinchbradm: yeah, the juju that deploys openstack wouldn't need to be multi-user unless you cared about having multiuser for controlling openstack itself04:37
natefinchbradm: you could definitely have whatever juju deploys on top of openstack be 2.0+ to get multi-user for those services04:37
natefinchbradm: the layers don't talk to each other at all.  As far as the top level juju is concerned, it doesn't know or care how openstack is deployed.04:38
bradmnatefinch: excellent, I thought that was the case but wanted to confirm before deploying with 1.25.3 for the underlying stack04:39
axwwallyworld: RB bot seems to be asleep, here's the first fix: https://github.com/juju/juju/pull/444205:08
wallyworldta, will look soon05:09
wallyworldaxw: damn, you and i are going to conflict :-)05:20
axwwallyworld: where? register?05:20
wallyworldmaybe elsewhere05:21
axwwallyworld: ah. my changes there are pretty trivial05:21
wallyworldyeah, i have 2 tests to fix before proposing, we can land yours first05:21
wallyworldaxw: so just to confirm, "-m model" works, and tags are without local-05:28
axwwallyworld: I'll bootstrap aws now to verify, but tested with lxd and -m model works05:28
anastasiamacaxw: wallyworld: when/if u get a chance, PTAL "simple"streams PR - surface difference increased somewot :P05:36
axwwallyworld: confirmed that tags don't have local in them, and I can do "juju status -m <controller-name-without-local-prefix>"05:42
axwanastasiamac: if you must have them at all: please move all of the bug references out of the production code, and into the tests that verify they're fixed05:44
axwif we break the code, the tests will fail and the broken tests will point at the bugs05:45
axwthen we don't have bug references littered all over the code05:45
anastasiamacaxw: sure05:48
axwwallyworld: based on your comment "we don't want one or the other", should we be changing the data sources to take a set of public keys?05:58
wallyworldaxw: we could do that, or create separate datasources. it's really a corner case for this image-metadata-url datasource. in practice, we don't have the private key used on cloud-images.u.c so maybe we just use the custom key if defined05:59
wallyworldand leave off the key if not defined06:00
axwwallyworld: so custom ones just use the "user signing key"? sounds sane06:01
wallyworldaxw: except that we also control the official key for tools06:01
wallyworldand so the qa guys may want to test that with a custom source06:01
axwsimple :)06:01
wallyworldstreams :-)06:02
wallyworldbut we do know what's an image vs tools data source so we can make a call there06:02
wallyworldexcept for the common data source at bootstrap06:02
wallyworldwhich points to a top level dir containing tools and images from memory06:03
wallyworldmaybe we construct a couple of data sources as needed and allow a signing verification error to be non fatal06:03
wallyworldi think that's what we do now06:03
axwwallyworld: different topic: would you be ok with temporarily reverting adding the "local." prefix altogether? then when we're through CI we can add it back, and change the initial mode to admin at the same time06:04
wallyworldaxw: sure, the thought had crossed my mind, but the pr landing now makes things good right?06:05
axwwallyworld: still can't destroy-controller with the controller name minus prefix06:06
axwwallyworld: dropping the prefix would fix that06:06
wallyworldwe were going to match local if there were no non-local?06:06
wallyworldthat might be a smaller change06:06
axwwallyworld: so I'm a bit reluctant to add that logic into jujuclient, which currently is agnostic of the names. but adding it in anywhere else would be error prone, given the number of places we're going to write them. and the spec doesn't call for it...06:08
wallyworldit is agnotic, it was to be a short term fix. the issue is that if we ship with the UX deviating from the spec in such a visible way, there may be issues06:09
wallyworldie fix for beta1, remove as soon as beta1 ships and Ci gets updated06:09
axwwallyworld: it's definitely not not going to be a smaller fix, btw. we'd need to canonicalise the controller names, which we currently expect are canonical06:11
wallyworldok, i guess we can release note it loudly06:11
axwwallyworld: and also already deviating from spec, since model is not admin06:11
wallyworldyes, but that's not as in your face :-)06:12
axwit should be trivial to fix both at the same time06:12
wallyworldlet's revert for beta106:12
wallyworldand we'll ensure Ci drops the -m etc at the same time06:12
axwwallyworld: another question I have is whether it should be local. or local: -- we use local: for clouds06:14
wallyworldyeah, and the spec uses local.model06:14
wallyworldwe can ask rick06:14
axwwallyworld: hrm actually it can't be local:, because then there'd be ambiguity with "local" as a controller name06:15
wallyworldah yes06:15
wallyworldaxw: right, time to see how bad the conflicts are06:17
* wallyworld takes a deep breath06:17
axwwallyworld: sorry :)06:17
axwshouldn't be too bad06:17
wallyworldtis all good06:17
wallyworld4 files06:19
axwanastasiamac: the answer to your last question on the PR is ^^^^06:24
axwwallyworld: (above "different topic")06:24
anastasiamacaxw: wallyworld: plz clarify in PR for posterity (and my sanity)06:29
anastasiamacaxw: m not seeing a definite answer above, just tossing ideas :D06:30
axwwallyworld: trivial one: http://reviews.vapour.ws/r/3881/06:49
dimiternaxw, hey, could this https://github.com/juju/juju/pull/4444 also fix bug 1546043?07:25
mupBug #1546043: unit tests leave apiserver/logsink.log behind <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1546043>07:25
axwdimitern: that's the one07:25
dimiternaxw, awesome! it was bugging me for a while now :)07:25
axwwallyworld: I'm going to rename the "create admin model..." card and create another one, since bulk of the work is done. just need to flip a switch to set it to admin07:29
axwactually I'll just create a new card and transfer points07:29
axwwallyworld: when you're done, can we have a chat about what's next?07:31
dimiternaxw, you've got a review btw, and I hope you don't mind - I assigned yourself to that bug07:31
axwdimitern: thanks, not at all07:31
wallyworldaxw: sure, more tests to fix, won't be long07:31
axwdimitern: master's blocked though, I'll land it once the beta's out I guess07:33
axwdimitern: why do we care about sorting the addresses w.r.t. v4/v6 on the client?07:36
dimiternaxw, that's ok - btw I've just confirmed your patch prevents apiserver/logsink.log creation07:36
axwdimitern: thanks07:36
dimiternaxw, ah, that due to the somewhat well-intended-but-not-well-implemented prefer-ipv6 setting07:37
axwdimitern: where does that preference actually matter though?07:38
axwdimitern: I'm wondering if we should care on the client07:38
dimiternaxw, it will change soon (first for maas, later for all providers gradually), as we're making controller endpoint selection based on spaces07:38
axwbecause we try all addresses07:38
dimiternaxw, we do try all of them, but we still put the last we successfully connected to on top07:39
dimiternaxw, and yeah, it shouldn't matter at the client side07:39
axwdimitern: ok, thanks07:40
axwwallyworld: ^^ maybe we don't need to worry about it anymore07:41
wallyworldthat would be good07:41
wallyworldaxw: quick chat now in standup channel?07:42
axwwallyworld: be there in a sec07:42
frobwaredooferlad_: running 15 mins late for our sync. sorry!08:20
wallyworldaxw: st.ModelUUID is different to st.Model().ComtrollerUUID() since the latter returns model.serverUUID08:23
axwwallyworld: the UUID of the admin model is the same as the controller UUID08:23
wallyworldaxw: i guess that's true but it seems then we're making an assumption that may change and the code as it is is immune to that08:24
axwwallyworld: there's also a controllerTag field on state, we could just expose that08:24
wallyworldok, maybe the latter is better08:24
axwwallyworld: avoids a db read08:25
wallyworldindeed, but mongo is web scale08:25
=== ashipika is now known as ashipika__
axwwallyworld: finished reviewing08:35
=== urulama__ is now known as urulama
axwanastasiamac: I suggest, for now, you change the image datasources just to use the user-supplied public key09:10
axwanastasiamac: nobody is likely to be using the official one with a custom location09:10
axwanastasiamac: and that's a separate issue as you noted in the bug09:11
axwanastasiamac: so, drop the ImagePublicKey function you added, and just use simplestreams.UserPublicSigningKey in the *image* data sources only09:11
axwanastasiamac: the tools ones should continue to use SimplestreamsJujuPublicKey09:11
frobwaredooferlad_: ping09:14
axwanastasiamac: you have a shipit once that's addressed09:16
frobwaredimitern: ping09:17
dimiternfrobware, pong09:17
frobwaredimitern: can we talk about L2 in the standup HO? If not convenient just say.09:17
dimiternfrobware, sure, sounds good09:19
dimiternfrobware, omw09:19
=== ashipika__ is now known as ashipika
axwwallyworld: still buggered: http://juju-ci.vapour.ws:8080/view/Juju%20Revisions/job/canonistack-deploy-trusty-amd64/4041/console09:22
wallyworldaxw: so it's just the kill. the cli *appears* ok09:24
wallyworldoh, also the connect09:25
wallyworldafter bootstrap, damn09:25
axwwallyworld: actually the kill worked, bootstrap returned an error code09:25
axwoh, maybe both failed actually09:25
axwwallyworld: cannot read controller info: model "canonistack-deploy-trusty-amd64:canonistack-deploy-trusty-amd64" not found09:26
axwfor bootstrap and kill09:26
wallyworldaxw: for legacy, we record foo:foo, in new client store, we want just foo, right09:26
wallyworldso maybe there's a mix up somewhere09:26
axwwallyworld: oh, my bad. bootstrap is failing due to ssh timeout09:27
axw... probably because canonistack09:28
axwand destroy is failing because it didn't bootstrap09:28
* axw checks a different substrate09:28
axwwallyworld: sorry, canonistack is non-voting. I'll raise the alarm if another voting substrate fails09:30
axwso far so good on azure..09:30
axwwallyworld: it's a little bit unclear, but I think that test you removed is to ensure we can connect with the addresses/creds on disk, without requiring the bootstrap config09:33
wallyworldok, i'll take a look09:34
axwwallyworld: winner: http://juju-ci.vapour.ws:8080/view/Juju%20Revisions/job/azure-arm-deploy/217/console09:46
wallyworldgoo :-)09:47
axwwallyworld: sorry, I didn't see that you had just changed the existing blank address check... leave it if you think there's potential for errors there09:55
wallyworldaxw: a bunch of tests fail which i am fixing. maybe we can hope juju itself is now not broekn anymore09:56
axwwallyworld: I'll have to go soon, but will check back later to see your changes09:57
wallyworldok, np, have a few to go09:57
axwwallyworld: or I can review tomorrow if you want to finish it tomorrow09:57
wallyworldwould be nice to land tonight, take a peek if you want later and hopefully will be +109:58
voidspacedimitern: frobware: http://reviews.vapour.ws/r/3884/11:16
dimiternvoidspace, looking11:17
fwereadedimitern, am bumping up against cmd/jujud/agent.MachineSuite.testAddresserWorkerNewResult11:18
fwereadedimitern, is it still relevant, or should we actually just never run it?11:18
dimiternfwereade, let me have a look11:18
fwereadedimitern, (or always? which would be bad, because it currently seems like "never" ;p)11:18
dimiternfwereade, ah, it's disabled as flaky11:19
dimiternfwereade, but we're dropping the address-allocation feature flag soon11:20
fwereadedimitern, indeed, but I want to know what the status is of the stuff it's dealing with11:20
dimiternfwereade, you mean whether to migrate it to use the dep engine?11:21
fwereadedimitern, I already have, I'm just not 100% sure what the expected behaviour is11:22
fwereadedimitern, and the agent tests are not making it any easier to figure out ;p11:22
dimiternfwereade, as it currently is, it should start and stop immediately when address-allocation feature flag is off (as it calls CanDeallocateAddresses first thing before it starts, which in turn uses the flag)11:23
dimiternfwereade, was that helpful? :)11:24
fwereadedimitern, it confirms that it's currently doing the right thing11:24
fwereadedimitern, and I think that *that* specific behaviour doesn't need testing at agent level11:24
fwereadedimitern, well, ok, it's arguable11:25
dimiternfwereade, agreed - those couple of tests effectively test the finished worker behavior11:25
fwereadedimitern, ehh, it's mainly just a bit annoying that my check-all-workers-are-running thing fails when one of the standard workers is sanely and blamelessly not running11:26
dimiternfwereade, ah :) I see11:27
fwereadedimitern, and while I *could* just ignore that skipped test I would *know* it'd fail against my current changes when reactivated, and that would be evil11:27
fwereadedimitern, so I need to take some action and am rambling at you in the hope that it will become clearer :)11:28
dimiternfwereade, I wouldn't worry too much about that particular test - perhaps an expected failure when not skipped + TODO will make it obvious?11:28
fwereadedimitern, it's still a timebomb for whoever hits it -- do you recall the nature of the flakiness?11:29
dimiternfwereade, yeah, it failed to pass under heavy load IIRC11:30
fwereadedimitern, ok, then I'm entirely unsurprised, bloody singularRunner patch :)11:30
* fwereade hopes what he has is a bit less awful11:31
dimiternfwereade, my point about not worrying too much about is that we'll drop the addresser soon anyway11:31
fwereadedimitern, that's even better then11:31
voidspacefrobware: thanks for the review11:32
dimiternvoidspace, I have a concern re updated dependencies.tsv btw11:33
voidspacefrobware: the uint comes from the gomaasapi Space object - so unrelated11:33
frobwarevoidspace: np, the only thing that really stuck out was int/uint for ID11:33
dimiternvoidspace, changing just the sha hash makes it difficult to compare the dates11:33
voidspacedimitern: how do I get the date? Running the update steps for dependencies.tsv shown in CONTRIBUTING.md omitted the date.11:34
voidspacedimitern: I can just put todays date in11:34
dimiternvoidspace, godeps github.com/juju/juju/...11:34
dimiternvoidspace, dumps the result at the end11:34
voidspacedimitern: with no dates11:35
voidspacedimitern: on my machine11:35
dimiternvoidspace, make sure you have the latest godeps11:36
dimiternvoidspace, go get -u -v launchpad.net/godeps/...11:37
voidspacefrobware: the "int" is purely to convert from the  float that comes out of json11:38
voidspacefrobware: I can use uint I suppose11:38
dimiternvoidspace, that's what I got on my in-progress branch when running godeps github.com/juju/juju/...: http://paste.ubuntu.com/15099666/11:38
voidspacedimitern: are you sure *you* have the latest version?11:38
dimiternvoidspace, yes, I did run go get -u -v launchpad.net/godeps/... before suggesting it :)11:39
voidspacedimitern: I've updated and I get dates11:39
voidspacedimitern: I'll add it11:39
voidspacedimitern: I've updated that11:40
mupBug #1546492 opened: It's difficult to debug-hooks storage hooks <juju-core:New> <https://launchpad.net/bugs/1546492>11:42
dimiternvoidspace, tyvm11:42
dimiternvoidspace, almost done with your review btw11:43
mupBug #1546492 changed: It's difficult to debug-hooks storage hooks <juju-core:New> <https://launchpad.net/bugs/1546492>11:45
voidspacefrobware: fmt.Sprintf("%.0f", float) works...11:45
voidspaceand is less round the houses11:45
dimiternnetwork.Id(fmt.Sprintf("%v", x)) will also work for v interface{} :)11:46
frobwarevoidspace: yep11:46
voidspacedimitern: but if x is a float %v will do the wrong thing11:46
voidspacedimitern: i.e. 2.0 will become network.Id("2.0") and we need network.Id("2")11:47
voidspacedimitern: and what comes out of json is a float even if the source is an int11:47
voidspacebecause json11:47
voidspacebecause javascript11:47
wallyworldaxw: if you're around, pr updated11:48
=== jamespag` is now known as jamespage
mupBug #1546492 opened: It's difficult to debug-hooks storage hooks <juju-core:New> <https://launchpad.net/bugs/1546492>11:48
dimiternvoidspace, uint(2.0) then?11:48
voidspaceor fmt.Sprintf("%.0f", v)11:50
voidspacerather than strconv.Itoa(uint(...))11:50
voidspacedimitern: frobware: did you get disconnected too or was it just me?11:53
voidspacedimitern: I don't think newAddressOnSpaceWithId should move to network11:57
voidspacedimitern: in future we'll be setting provider id *or* name11:57
voidspacedimitern: at which point we'll probably need a "NewAddressOnSpaceId11:57
voidspacedimitern: this PR is a little bit of an intermediate one where we're setting both, but it won't stay like this11:57
voidspacedimitern: probably next PR...11:57
frobwarevoidspace:just you11:58
voidspacefrobware: weird11:58
dimiternvoidspace, I think freenode is experiencing DDoS attacks today (yet again)11:58
voidspacedimitern: ah12:00
dimiternvoidspace, I'm not sure about "or"12:00
frobwarevoidspace: I take it back.12:00
voidspacefrobware: hehe12:00
voidspacedimitern: that's the current plan12:00
voidspacedimitern: we shouldn't use space names directly from the provider12:00
voidspacedimitern: so if the space comes from the provider we should set the id not the name12:00
voidspacedimitern: so if we have a name set we *know* it's a juju name12:01
dimiternvoidspace, what's wrong with having either name and no ID or both?12:01
voidspacedimitern: rather than having a mix of juju names and provider names floating through our code12:01
frobwaredimitern, voidspace: why can't we indirect through the ID for the name?12:01
voidspacedimitern: because if you see a name on an address you need to know if it's a juju name or provider name12:01
voidspacefrobware: we should do, that's what I'm saying12:02
dimiternvoidspace, frobware, I think a space name should always be a valid juju name12:02
voidspacefrobware: we won't have an id for ec2 addresses of course because there's no provider id12:02
voidspacedimitern: but that isn't currently the case with maas12:02
voidspacedimitern: and our current definition of "valid juju name"12:02
voidspacedimitern: if they change to be in sync that's a different matter12:02
voidspacebut even then there's no *problem* with being strict on using id *or* name - there's just less need12:03
voidspacebut at the moment there's a need12:03
dimiternvoidspace, yeah - they should change in names so that [A-Za-z0-9-_]+ is a valid juju space name12:04
dimiternvoidspace, but as it will be the case in maas12:04
dimiternvoidspace, s/but//12:05
voidspacedimitern: yep12:05
dimiternvoidspace, that's why I suggested to keep the name even if we have an ID12:05
voidspacedimitern: my next PR will address this anyway, so I'm going to drop that issue from this PR12:05
voidspacedimitern: the trouble is that until they do it (which they say they will but may never do) it's dangerous to mix up juju names and maas names12:06
dimiternvoidspace, I'm ok with that12:06
voidspacedimitern: cool12:06
frobwarevoidspace, dimitern: totally agree with "it's dangerous to mix up juju names and maas names" +112:08
dimiternfrobware, voidspace, the only danger I can see is due to bugs in maas atm12:11
frobwaredimitern: we should stop working around bugs, IMO. fix the root cause.12:12
axwwallyworld: are you still working on changing UpdateControllerAddresses to not take UUID?12:13
dimiternfrobware, I'm not saying we should work around the bugs in maas that prevent us in some cases to use a valid maas space name as a juju space name12:14
voidspacedimitern: well, that maas space name definition is broader than juju is not a "bug", it's due to a lack of communication between us12:14
voidspacedimitern: it sounds like they will fix it though12:14
voidspacedimitern: duplicate names are a bug :-)12:14
wallyworldaxw: it takes a controllerUUID in one case - after api login when controller name is not known, only uuid. i guess i could look up controller name at that point12:15
dimiternvoidspace, yeah - spaces allowed in names and duplicate names are 2 bugs they need to fix12:15
axwwallyworld: when would we ever not know the controller name?12:15
dimiternvoidspace, they said they'll fix those two and we should consider them "fixed" - i.e. build our code onto that assumption12:16
wallyworlddamn, in that one place, i didn't see we had controlle rname12:16
wallyworldi'll rework a bit12:16
dimiternvoidspace, which means if it's not so - i.e. CI maas setups or other (older) 1.9 maas deployments won't work12:17
dimiternuntil those bugs are fixed12:17
blahdeblahRepeating earlier question: Why does juju mangle /root/.ssh/authorized_keys, and what I can do to fit in with that, whilst still enabling my charm to write a working entry in there?12:21
wallyworldaxw: updated, feature test for register runs ok12:26
axwwallyworld: ok, looking in a sec. I noticed in CI that manual bootstrap fails because we're now expecting "juju bootstrap manual/<host>", and CI is passing bootstrap-config in config.ayml12:26
axwwallyworld: should I try and fix it, or just ask CI to retest with that small change?12:27
wallyworldaxw: yeah, saw that too, i beliebe aaron knows about that12:27
axwwallyworld: we could allow bootstrap-host in config as well, would be better not to deviate from other providers tho12:27
wallyworldi will ask them to re-test tomorrow, i prefer consistency12:28
axwwallyworld: LGTM, thanks for changes12:29
wallyworldaxw: np, thanks for review, Ci looking good too12:30
wallyworldexcept for manual of course12:30
axwwallyworld: and a few things say they're still pending, but yeah, lots of green :)12:31
wallyworldrelease notes tomorrow, will be quite an essay12:32
=== perrito667 is now known as perrito666
voidspacedimitern: frobware: my branch has an unrelated failure in featuretests13:15
voidspacedimitern: frobware: it's actually a space discovery related failure (can't login)13:15
voidspacedimitern: frobware: I'll land my branch on maas-spaces2 and fix this failure with a follow-up on master13:15
dimiternvoidspace, sounds good +113:18
jcastrois there a quick getting started guide on building juju from source?13:40
jcastroI think I found a bug in the alpha but I wanted to confirm with trunk13:40
Ursinhajcastro, maybe there's a ppa with daily builds from trunk?13:44
Ursinhathat would be a good idea regardless :)13:44
Ursinha(I realize this is not what you're asking for but figuring out such ppa would make me happy as well solve your problem to test trunk :))13:46
jcastroyeah I am wondering why there's not just a daily PPA13:50
rick_h_natefinch: wasn't there a thread recently that talked about a doc on building juju core? I can't seem to find it and thought you replied in it.13:59
rick_h_Ursinha: jcastro we're looking at ways to get builds out faster. Because of the use of streams and such, we don't do daily builds. We need a less invasive way to get that out.14:00
natefinchrick_h_: it's not really very well written for first timers: https://github.com/juju/juju/blob/master/CONTRIBUTING.md14:06
rick_h_natefinch: ah ok thanks14:06
natefinchrick_h_: we really should write a step by step "this is how you build juju"... which I think that document wants to be, but tries to do too much, and so obscures the actual steps you need to do to build14:07
rick_h_natefinch: agreed, good to find this and we'll see what we can do.14:07
alexisbnatefinch, I used that doc for my first build, wasn't too bad14:10
natefinchfwereade: heh, oops.  Wanted to ask about uniter tests14:12
mupBug #1546561 opened: juju sets wrong default gateway for lxc containers when using JUJU_DEV_FEATURE_FLAGS=address-allocation <juju-core:New> <https://launchpad.net/bugs/1546561>14:15
mupBug #1546561 changed: juju sets wrong default gateway for lxc containers when using JUJU_DEV_FEATURE_FLAGS=address-allocation <juju-core:New> <https://launchpad.net/bugs/1546561>14:18
mupBug #1546561 opened: juju sets wrong default gateway for lxc containers when using JUJU_DEV_FEATURE_FLAGS=address-allocation <juju-core:New> <https://launchpad.net/bugs/1546561>14:24
natefinchredacting the API params during tests is dumb.14:31
=== Ursinha_ is now known as Ursinha
fwereadenatefinch, oops sorry; uniter tests?14:34
natefinchfwereade: there's a bunch of "match hooks" where we expect a specific list of hooks to be fired.  I presume that if that list changes, that's a bad thing?  I'm still working on this resources code, and what I'm getting is an extra upgrade-charm hook firing14:36
perrito666uh, that part still exists?14:36
natefinchunless something changed in the last 5 or 6 days?14:37
perrito666I hoped that to go in the uniter refactor sprint14:38
natefinchalso, it seems like there's a bug, or at least an inefficiency in the matchHooks code: https://github.com/juju/juju/blob/master/worker/uniter/util_test.go#L25014:38
natefinchThis match hooks call gets retried until a LongWait expires... but really, after the first time this check fails, we know it'll never ever pass14:39
perrito666natefinch: it is not a bug, its a feature :p14:40
natefinchwe don't ever remove things from the hooksCompleted list, so if one of them doesn't match... that's it, we're done, it'll never match.14:40
perrito666no, really its a design flaw14:41
perrito666that whole thing is a big bad idea, it is depending a lot on an implementation accident14:42
perrito666but fwereade might not agree with me :p14:42
natefinchyeah, that was my question... I'm changing the implementation slightly... in theory it should fire the exact same events that it did before, but it's possible some niggling bits in watcher/worker code cause a hook to fire more than once... so I can't tell if I've introduced a bug, or if the tests are just too specific about their expectations.14:43
perrito666ok, fwereade might correct me here, tests rely on a hook order that we dont really guarantee, much of the fact that the expected and obtained hook match depends on delicate time balance14:45
natefinchsom, for example, here's what my change does to the "SteadyStateUpgrade" hooks: http://pastebin.ubuntu.com/15100335/  (I changed the line prefixes so they make more sense without looking at the code, and so the lists match up for easier visual comparison)14:46
natefinch(that used to be ctx.hooks vs. ctx.hooksCompleted)14:47
perrito666natefinch: you are triggering more hook calls, which is not bad per se14:50
frobwarefwereade: maybe related to your login issue ^^ "voidspace> dimitern: frobware: it's actually a space discovery related failure (can't login)"14:57
frobwaredimitern, voidspace: release note sync15:03
voidspacefrobware: oops, soory - lost track of time15:06
voidspacefrobware: 5 mins, grabbing coffee15:06
dimiternoops sorry, omw15:11
katconatefinch: ericsnow_: just want to o/ since no standup in the morning15:19
katconatefinch: ericsnow_: how's everything going?15:20
voidspacedimitern: frobware: http://reviews.vapour.ws/r/3886/15:20
ericsnow_katco: good15:21
ericsnow_katco: talked with Ian about that worker15:21
voidspacefrobware: fwereade: what login issue?15:21
=== ericsnow_ is now known as ericsnow
katcoericsnow_: yeah? what's the consensus15:21
ericsnowkatco: we don't need a worker for that15:22
ericsnowkatco: the precedent (downloading lxc images) indicates that a worker should not be used15:22
katcoericsnow: it occurred to me this morning that maybe i didn't represent it accurately. this will be running 100% of the time polling the charm store for all the services, correct?15:23
ericsnowkatco: no15:23
ericsnowkatco: that is a different worker15:23
katcoericsnow: oh, i see you picked up a diff. card15:23
katcoericsnow: ok, so the download worker, is not a worker. gotcha. what is it?15:23
ericsnowkatco: the one we were discussing related to using a worker to download from the charm store into state in response to resource-get15:24
mupBug #1546272 changed: doc: docs/devel/developer-layers-interfaces typo: get_remove <docs> <juju-core:Invalid> <https://launchpad.net/bugs/1546272>15:24
=== Ursinha_ is now known as Ursinha
ericsnowkatco: in the API code we stream directly from the charm store into the blob store15:25
ericsnowkatco: (API server side)15:25
katcoericsnow: and if the stream errors out?15:25
ericsnowkatco: since resource-get blocks a worker doesn't add anything15:25
ericsnowkatco: then we retry (on the server side)15:25
katcoericsnow: what's the mechanism for doing so?15:26
ericsnowkatco: the usual suspect: utils.AttemptStrategy15:26
* natefinch is here but doesn't want to interrupt.15:26
katconatefinch: it's irc ;)15:26
natefinchkatco: :)15:27
katcoericsnow: ok, well glad you worked it out. thanks for bringing it up15:27
katcoericsnow: natefinch: i'm working on release notes for resources; i'll want you to review here in a bit15:28
ericsnowkatco: also, per wallyworld regarding workers: "workers are more for reacting to changes in state"15:28
ericsnowkatco: no, thanks for the discussion15:28
natefinchkatco: the uniter tests are a beast.  There are currently about 5 failures that I'm trying to determine if they represent bugs I have introduced, or tests that need to be updated.15:28
katcoericsnow: good to know15:28
ericsnowkatco: it helped paint an even clearer picture about workers in general :)15:28
katconatefinch: :( i understand those are difficult to deal with. thanks for reaching out to perrito666. we need that done today, so do whatever is needed to make that happen (e.g. pair if necessary)15:29
katcoericsnow: definitely15:29
ericsnowkatco: FYI, wallyworld also pointed me to the "charmrevisionupdater" worker as something similar to the charmstore poller I'm writing for resource info15:30
katconatefinch: ericsnow: btw we have a new card we need to point: validating file extensions15:30
katcoericsnow: oh, awesome!15:30
ericsnowkatco: it's not particularly re-usable for this, but does provide an example; and validation that I'm on the right track :)15:31
katcoericsnow: just as useful imo :)15:31
ericsnowkatco, natefinch: I'm free to point that whenever y'all are ready15:31
natefinchfwereade: let me know if you come available15:32
katcoericsnow: natefinch: gimme 5 and we'll hop in moonstone?15:32
natefinchericsnow katco sounds good15:32
ericsnowkatco: +115:33
katcoericsnow: natefinch: ok i'm in there15:38
fwereadefrobware, voidspace: nah, I was being dumb, had changed a client-side code path without full awareness15:54
fwereadenatefinch, perrito666: sorry! short version: I am inclined to consider unexpected hook firings to be a problem15:55
fwereadenatefinch, I am available, just quite deep into code, sorry15:56
natefinchfwereade: understandable. that was my assumption as well.15:56
fwereadenatefinch, cool15:56
fwereadenatefinch, it *may* be the case that the layers of indirection around the tests are such that we can't reliably induce specific uniter behaviour, but that's still a problem15:58
fwereadenatefinch, by the way, I think I'm misunderstanding something -- did I see a recent mail from jam saying that new resources are only delivered on resource-get?15:59
fwereadenatefinch, is it the case that we do an upgrade-charm to inform of new *available* resource versions or something, but nothing has actually changed in the charm at that point?16:00
=== kwmonroe_ is now known as kwmonroe
natefinchfwereade: we fire upgrade-charm when you push up a local resource to the controller.  At that point, the unit does not have the bytes from the new resource, and must call resource-get16:03
fwereadenatefinch, upgrade-charm seems a bit surprising compared to resources-changed or something?16:04
fwereadenatefinch, the only connection I can see is that they're both sort of to do with the charm, and you can say that about almost anything ;p16:06
natefinchfwereade: the idea is that the resource bytes are integral to the functionality of the charm. So changing a resource is just as disruptive as changing the charm version16:06
natefinchfwereade: firing upgrade-charm is what is declared in the spec, per rick_h_, mark, jam, etc16:07
fwereadenatefinch, oh joy16:07
* natefinch is Not In Chargeā„¢16:08
fwereadenatefinch, we start by saying "charm logic and payloads can vary independently, let's add tooling to make those use cases easier" and we end up with "upgrade-charm now means two completely distinct things, have fun charmers!"16:08
* marcoceppi watches as this develops16:09
* fwereade turns to marcoceppi and gestures vaguely -- if this *is* a happy outcome for you and those you represent, that's awesome -- is it?16:10
natefinchmarcoceppi, fwereade: http://media0.giphy.com/media/4pMX5rJ4PYAEM/giphy.gif16:11
fwereadenatefinch, haha16:11
marcoceppifwereade: I had concerns of not being a hook available, but was convinced that this was okay. If there's still a way to get a hook I'd be happier16:11
marcoceppifwereade: if charms have a way to query the version of the resource, without fetching it, then it's not that bad. Just some additional logic in upgrade-charm to determine if it's is new charm code or new resources16:12
fwereademarcoceppi, yeah, absolutely, any state we show you as a charmer *should* be guarded by some hook that's guaranteed to fire if it changes16:12
fwereademarcoceppi, or both ;p16:13
marcoceppibut I'd rather have this feature with upgrade-chram than delay to 2.116:13
marcoceppiwe can build libraries in the new reactive framework to work around this16:13
marcoceppior rather, not work around, but enhance this16:13
fwereademarcoceppi, sure, understood, I'm just digging to check that "when we introduce new state to charmers, we should introduce new hooks to inform of changes to same" fits with your baseline desires16:15
marcoceppifwereade: I'd prefer new hooks, the more granular the event dispatcher the better16:16
fwereademarcoceppi, because, y'know, if we don't tell you about the changes that's obviously stupid, and if we repurpose old hooks we potentially expose latent bugs all over the charm store by changing what hooks will get run in what situations16:16
fwereademarcoceppi, cool16:17
fwereademarcoceppi, to put it another way: you *can* work around a mish-mash of events, many of which mean "some combination of X, Y and Z distinct things changed", but it kinda sucks to have to16:18
marcoceppiin so many words16:18
marcoceppiwith the exception of the hook thing, th eresources stuff is brilliant16:19
katcofwereade: marcoceppi: sorry, just read through the backscroll16:22
katcofwereade: marcoceppi: i think the reason that decision was made is because resources never stand alone, it's always the tuple of the charm and resources that is the concept to consider16:23
marcoceppiright, but you can also upgrade resources seperately from the charm16:24
katcofwereade: marcoceppi: so having being notified of a resource being updated is meaningless if you accept that premise16:24
katcomarcoceppi: my understanding is that you cannot16:24
marcoceppiI was informed otherwise16:24
katcomarcoceppi: resource updated = new rev of the charm16:24
marcoceppibut since you've done the work I'm happy to accept that16:24
katcomarcoceppi: who am i contradicting?16:24
marcoceppiso if I release a new version of my applicaiton, that's a charm rev?16:24
katcomarcoceppi: yep16:25
marcoceppibut it's just an updated resource16:25
rick_h_marcoceppi: the 'revision' of a charm becomes a 'revision set'16:25
rick_h_marcoceppi: that set is the published set of the charm rev, and the rev of each resource16:25
rick_h_marcoceppi: updating any part of that, is an new revision set that much be processed by the upgrade-charm hook.16:26
rick_h_that's the way it's currently set out.16:26
katcomarcoceppi: check out the 3rd bullet of the 1.0 mvp16:26
marcoceppiokay, so is there a way for me to query, without first accepting the payload, that I've got a new version?16:26
marcoceppiin the charm16:26
katcomarcoceppi: as a charmer, not currently. as an admin, yes16:26
rick_h_marcoceppi: we need that yes. It's not there now, but agree. Honestly it was an optimization thing that came up as we get into using it16:26
rick_h_marcoceppi: and good feedback that we need to go back with16:27
marcoceppithen I'm cool16:27
katcomarcoceppi: you are cool, marcoceppi.16:27
marcoceppias long as I can say "resource update"16:27
katcovery cool :)16:27
marcoceppiat the end of the day, with reactive, we're not going to care about upgrade-charm hook16:27
marcoceppiwell some will, most wont16:27
rick_h_marcoceppi: katco I think we need something like resource-version or resource-changed to go with resource-get. My concern with resource-changed is that if something fails and you retry, will we have the right answer.16:27
marcoceppiwe'll only really care about @when('resource.<RESOURCE_NAME>.updated')16:27
rick_h_marcoceppi: katco so I think there's some thought we need to get that right16:28
katcorick_h_: well, isn't resource-changed redundant? i.e. anytime it would fire, upgrade-charm would also have fired16:28
rick_h_katco: not as a hook, but as a hook command16:28
rick_h_katco: e.g. resource-changed mysourcecode16:28
rick_h_returns true/false16:28
marcoceppirick_h_ katco is resource-list a hook-tool?16:29
rick_h_katco: so if one new resource is uploaded out of 3, I can tell which one I need to untar, process, etc16:29
katcomarcoceppi: no, juju list-resources16:29
fwereadekatco, rick_h_: the issue is surely that upgrade-charm means "your charm logic has changed" and resource-changed means "some of your tweakable blobs have changed"16:29
katcorick_h_: well, that is an optimization. i believe resource-get on a resource that hasn't changed is a nop16:30
marcoceppiso, as a charmer, I want to be able to run "resource-list" in a hook with --format json and get something like "resource_name": "version" for each resource16:30
rick_h_katco: I'm not so sure16:30
fwereadekatco, rick_h_: that we have a tuple of things that represent "exactly what's running on this unit" is... coincidental, if you like? we don't even officially expose charm urls to charmers right now16:30
katcoericsnow: natefinch: is resource-get on an unchanged resource a no-op right now?16:31
natefinchFWIW, we certainly could add a command that tells the unit whether or not it has the latest version of a resource.  We store the version each unit has and the version that is current for the service.16:31
rick_h_fwereade: well it was designed/built to not be coincidental. I see what you mean on "charm logic" vs "blob of data" though.16:31
rick_h_fwereade: the goal is that when you publish to the charmstore you're declaring "this revision of the charm logic with this revision of this blob and that blob pass tests and work together"16:32
marcoceppinatefinch: exposing that I think will be crucial to making the join charmversion + resourceversion + upgrade-charm work for a charm authors perspective16:32
rick_h_fwereade: it's the local case that's more muddy16:32
katcorick_h_: fwereade: yeah it all begins at 1st principles. either the tuple defines the charm, or it doesn't. if it does, then there's no such thing as updating just the blob16:32
rick_h_marcoceppi: +1 the thing is catching the failure cases and making sure it behaves predictably16:32
natefinchkatco: we don't do that optimization... resource-get will always just download the bytes16:33
katconatefinch: fair enough for v116:33
rick_h_natefinch: right, I think we can't noop right now because it means the hooks aren't idempotent16:33
katcorick_h_: mm not true16:33
fwereadenatefinch, katco: so the upshot is that every time you get an upgrade-charm, you *have* to resource-get *all* your resources before you can safely move on?16:33
natefinchrick_h_: sure they are... the bytes on disk are the same before and after16:33
katcorick_h_: idempotent = end state is always the same16:33
rick_h_katco: ah, I see. the bytes are in the folder16:33
katcorick_h_: correct16:34
natefinchfwereade: yes :/16:34
katcofwereade: yeah, as designed currently\16:34
fwereadehow does this even happen with a supposed "user focus" in design?16:34
rick_h_fwereade: no, it just means you have to process your logic.16:34
rick_h_fwereade: happy to hop on a call if you've got questions16:34
katcorick_h_: would join to be a fly on the wall16:34
rick_h_fwereade: but you're starting to cross into unproductive territory here16:34
fwereaderick_h_, let's, I fear that I misunderstand something horribly16:35
rick_h_https://plus.google.com/hangouts/_/canonical.com/rick?authuser=1 for all interested parties16:35
perrito666I think I broke RB17:08
perrito666k people bbl17:10
mupBug #1544796 changed: Backup restore fails: upgrade in progress <backup-restore> <blocker> <ci> <regression> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1544796>17:28
mupBug #1544796 opened: Backup restore fails: upgrade in progress <backup-restore> <blocker> <ci> <regression> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1544796>17:37
mupBug #1544796 changed: Backup restore fails: upgrade in progress <backup-restore> <blocker> <ci> <regression> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1544796>17:40
mupBug #1544796 opened: Backup restore fails: upgrade in progress <backup-restore> <blocker> <ci> <regression> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1544796>17:43
mupBug #1544796 changed: Backup restore fails: upgrade in progress <backup-restore> <blocker> <ci> <regression> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1544796>17:49
mupBug #1546662 opened: juju does not respect --agent-version <bootstrap> <ci> <juju-core:Triaged> <https://launchpad.net/bugs/1546662>17:58
mupBug #1546662 changed: juju does not respect --agent-version <bootstrap> <ci> <juju-core:Triaged> <https://launchpad.net/bugs/1546662>18:01
perrito666anyone ever heard of StateServerInstances() ?18:12
mupBug #1546662 opened: juju does not respect --agent-version <bootstrap> <ci> <juju-core:Triaged> <https://launchpad.net/bugs/1546662>18:13
mupBug #1546662 changed: juju does not respect --agent-version <bootstrap> <ci> <juju-core:Triaged> <https://launchpad.net/bugs/1546662>18:16
perrito666fwereade: still here?18:16
perrito666fwereade: nevermind18:17
mupBug #1546662 opened: juju does not respect --agent-version <bootstrap> <ci> <juju-core:Triaged> <https://launchpad.net/bugs/1546662>18:19
perrito666mup: you are a very annoying thing18:19
mupperrito666: Strictly speaking, I'm not intelligent enough to understand that.18:19
perrito666it shows18:20
natefinchkatco: so in talking with william and rick, it sounds like we really need a hook command that can tell the charm what resources are out of date for the unit.  That should be really easy, since we have all the backend code, we'd just replicate a bunch of juju resources <unit> in a hook command.18:40
katconatefinch: i agree that sounds like a good idea. let's revisit after we deliver what's on our plate already18:43
natefinchkatco: yep... and FWIW, rick was able to convince william that we should stick with the charm-upgrade hook, mostly because it's sorta too late to do anything else.18:46
katconatefinch: yeah18:46
katconatefinch: i wonder if we looked at how we support things, we couldn't support releasing changes like that more easily18:47
natefinchkatco: I think making a new hook wouldn't been the end of the owrld, but it woudl definitely be  a few more days work than finishing up what we have... and we don't really have a few days to spare.18:47
katconatefinch: then the conversation becomes, "that's a good idea. we'll do that next month" instead of "omg change course! change course! we can't have a breaking change!"18:47
natefinchkatco: rick was positing that it could be delivered later... I'm not 100% convinced that's true, though, since it would break charms that rely on charm-upgrade getting called.18:48
natefinch(for resource changes)18:48
katconatefinch: we should make more liberal use of our versioned concepts outside of the macro version of juju18:48
katconatefinch: and deprecate old versions of things more regularly (apis, hook commands, cli)18:49
natefinchkatco: well, yeah, we should deliver min-juju-version, which would help with that18:49
katconatefinch: true18:49
natefinchkatco: (in our spare time)18:51
natefinchperrito666: you back yet?18:51
natefinchsuper short review for someone?  re-enables showing full API params during tests (if you use the verbose flag during the test). http://reviews.vapour.ws/r/3887/diff/#19:02
voidspaceEOW, bye all19:12
natefinchgah, what I wouldn't give for focused unit tests in the uniter code, so I could narrow down where the bug is in my code :/19:23
katconatefinch: i think you and ericsnow better pair up to get through this19:39
natefinchkatco: yep19:40
natefinchkatco: sorry, missed when he came back online.19:40
natefinchericsnow: help me ericsnowcurrently, you're my only hope!19:41
ericsnownatefinch: let's get it done!19:41
katcoericsnow: natefinch: i'm done with admin stuff. reviewing your code now19:42
rick_h_cherylj: I've got to get the boy from school and will be late to our meeting with folks. Can you bug thumper please?19:56
rick_h_cherylj: I'll have to work with him to move that back since it's sitting in this bad spot19:56
cheryljrick_h_: sure, will do19:57
=== urulama is now known as urulama__
* thumper heading to dentist with daughter two20:42
rick_h_thumper: doh, looks like I missed you20:43
davecheney0 for 2 rick_h_20:55
rick_h_davecheney: yea, he's avoiding me. Scheduling things during school time and then running off to dentists.20:56
perrito666Katco I won't make it to your standup, stuck in traffic sorry21:23
katcoperrito666: np, i just marked you and anastasiamac as optional21:23
wwitzel3perrito666 do it from the car :P21:23
perrito666I can IRC from traffic jams, how cool is that?21:24
perrito666Honestly if the lte dongle wasn't in the trunk I could21:24
wwitzel3ahh, the person grabbed it from you as you pushed them in there?21:25
perrito666There is no respect anymore21:26
* perrito666 shouts at the trunk21:28
perrito666Traffic is moving bbl21:35
* perrito666 is back21:53
perrito666wallyworld: around?22:02
wallyworldin a meeting22:05
natefinchericsnow: sorry... I'll give that a test and see if it needs tweaking or anything22:06
natefinchericsnow: thanks for the help22:06
ericsnownatefinch: cool22:06
=== natefinch is now known as natefinch-afk
perrito666yay go 1.622:23
marcoceppiperrito666: time to pack it up and move juju to 1.6 ;)22:28
bogdanteleagaI'm actually thinking of going back to an older version to save those insane compilation times22:33
perrito666bogdanteleaga: the only way to advance is forward22:38
mupBug #1546790 opened: availability zone not set <juju-core:New> <https://launchpad.net/bugs/1546790>22:40
bogdanteleagaperrito666, at least by golang 2.0 the test suite run time won't be the bottleneck22:41
mupBug #1546794 opened: lxd provider's namespace property seems to be ignored <juju-core:New> <https://launchpad.net/bugs/1546794>22:58
mupBug #1546795 opened: bootstrap manual broken: failed to check provisioned status: subprocess encountered error code 1 <juju-core:New> <https://launchpad.net/bugs/1546795>22:58
mupBug #1546794 changed: lxd provider's namespace property seems to be ignored <juju-core:New> <https://launchpad.net/bugs/1546794>23:01
mupBug #1546795 changed: bootstrap manual broken: failed to check provisioned status: subprocess encountered error code 1 <juju-core:New> <https://launchpad.net/bugs/1546795>23:01
mupBug #1546794 opened: lxd provider's namespace property seems to be ignored <juju-core:New> <https://launchpad.net/bugs/1546794>23:11
mupBug #1546795 opened: bootstrap manual broken: failed to check provisioned status: subprocess encountered error code 1 <juju-core:New> <https://launchpad.net/bugs/1546795>23:11
* perrito666 prepares for standup, suddenly remembers there is no standup today23:13
wallyworldperrito666: anastasiamac: axw: meeting finished early, let's have standup23:27
mupBug #1546805 opened: storageprovider seems to be stuck in an infinite loop <juju-core:New> <https://launchpad.net/bugs/1546805>23:29
mupBug #1546805 changed: storageprovider seems to be stuck in an infinite loop <juju-core:New> <https://launchpad.net/bugs/1546805>23:35
mupBug #1546805 opened: storageprovider seems to be stuck in an infinite loop <juju-core:New> <https://launchpad.net/bugs/1546805>23:38

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