/srv/irclogs.ubuntu.com/2016/05/26/#juju-dev.txt

davechen1yping alexisb00:37
alexisbheya davechen1y00:38
alexisbwhats up?00:38
davechen1yalexisb: i just sent you an email that requires acknowledgement00:38
davechen1yit's very short, could you please read and respond00:38
davechen1ythanks00:38
alexisbdavechen1y, will do00:38
davechen1ythanks00:39
alexisbdavechen1y, responded00:41
davechen1yalexisb: ta00:41
davechen1yok, next question00:45
davechen1yJFDI or not JFDI00:45
davechen1yi have a PR that is at the bottom of a lot of blocked bugs for beta800:45
davechen1ycan I JFDI ?00:45
anastasiamac_davechen1y: is it blocker? u can't just use $$fixes-blah$$?00:47
davechen1yanastasiamac_: i don't know00:49
davechen1ythe issue i am assigned is not the one that is blocking landing00:49
anastasiamac_ic. is it the race fix?00:49
davechen1yyes00:50
davechen1ywell00:50
davechen1ymaybe00:50
davechen1ythis is not the issue that CI is blocked o00:50
davechen1yon00:50
anastasiamac_so u r right, plz do not JFDI unless u have an explicit "please land" from alexisb or cherylj or sinzui00:51
davechen1yok, i've marked my PR as blcoked on the landing bot and i'll work on something else00:51
anastasiamac_\o/00:51
davechen1yhow can I find out when this build was run http://reports.vapour.ws/releases/3993/job/run-unit-tests-race/attempt/149500:52
davechen1ythis is the last race build that was run00:52
davechen1yi require the CI rae infrastructure to validate the fixes I am landing00:52
davechen1yis the ci race build running currently ?00:52
sinzuidavechen1y: follow the link to the build number in the top nav. http://reports.vapour.ws/releases/3993  Wed May 25 08:59:46 201600:54
davechen1yi get a 40400:54
davechen1ywhen I follow that link00:54
davechen1ysorry, i get a 404 when I follow the link to the jenkins job00:55
sinzuidavechen1y: are you no longer a member oc canonical?00:55
davechen1ysinzui: one can only hope00:55
sinzuidavechen1y: jenkins jobs only last a few days. All the data is on the reports site00:55
davechen1ysinzui: so does that mean the race job has not run for at least a few days ?00:56
davechen1yrun-unit-tests-race1495Bug #157905100:56
mupBug #1579051: Race in juju/controller/destroy and TestDestroyCommandConfirmation <blocker> <ci> <intermittent-failure> <race-condition> <regression> <juju-core:Fix Released by thumper> <https://launchpad.net/bugs/1579051>00:56
davechen1y^ this bug that the race build is complaining about is marked fixed release00:56
sinzuidavechen1y: no. the job is run with every revision00:56
davechen1ysinzui: that doesn't make sense00:57
davechen1yif run-unit-tests-race 1495 was run recently, as in since last night then the jenkins job would be 40400:57
davechen1ywouldn't be 40400:57
sinzuidavechen1y: if you cannot seen any the job at all, then you need to login. 90% of the site is not public because juju likes to send my credentials to logs.00:57
davechen1ysinzui: i dont' have a login for that site00:58
davechen1yor chrome has forgotten them :(00:58
mupBug #1585836 opened: Race in github.com/juju/juju/provider/azure <azure-provider> <ci> <race-condition> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1585836>01:10
mupBug #1585836 changed: Race in github.com/juju/juju/provider/azure <azure-provider> <ci> <race-condition> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1585836>01:22
=== Makyo is now known as Makyo|away
mupBug #1582408 changed: System id is listed during bootstrap and deploy of charms instead of system name <usability> <juju-core:Triaged> <https://launchpad.net/bugs/1582408>01:28
mupBug #1585836 opened: Race in github.com/juju/juju/provider/azure <azure-provider> <ci> <race-condition> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1585836>01:28
wallyworldaxw: a small one when you are free http://reviews.vapour.ws/r/4905/01:29
=== natefinch-afk is now known as natefinch
mupBug #1582408 opened: System id is listed during bootstrap and deploy of charms instead of system name <usability> <juju-core:Triaged> <https://launchpad.net/bugs/1582408>01:31
axwwallyworld: what changed the error message change?01:31
wallyworldaxw: new dep i suspect01:32
wallyworldhttprequest maybe01:32
axwwallyworld: that function just uses net/http AFAICS01:32
wallyworldaxw: yeah, i have no idea why that message changed then, i can look into it i guess, i hust assumed it was due to one of the new deps01:34
axwwallyworld: please do, doesn't look related to me01:34
wallyworldok, otp will do soon01:34
* redir goes eod01:35
mupBug #1582408 changed: System id is listed during bootstrap and deploy of charms instead of system name <usability> <juju-core:Triaged> <https://launchpad.net/bugs/1582408>01:40
axwwallyworld: I see you reverted, did you get to the bottom of it?02:37
wallyworldaxw: nope, master failed in the same way, nfi02:38
mupBug #1585846 opened: worker/terminationworker: test timeout after 20 minutes <juju-core:New> <https://launchpad.net/bugs/1585846>02:40
mupBug #1585847 opened: LXD creates all the interfaces as the physical machine has when using MAAS. <juju-core:New> <https://launchpad.net/bugs/1585847>02:40
wallyworldaxw: you happy to +1 with that error message reverted?02:48
axwwallyworld: yep, will do02:48
wallyworldta02:48
axwwallyworld: done02:49
wallyworldty02:49
mupBug #1585849 opened: Azure native bundle 404 creating resources <azure-provider> <bundle> <ci> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1585849>03:10
mupBug #1585851 opened: Cannot restore-backup of controller model <backup-restore> <ci> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1585851>03:10
mupBug #1585856 opened: worker/txnpruner: test failure during ci <juju-core:New> <https://launchpad.net/bugs/1585856>03:31
mupBug #1585857 opened: Unable to bootstrap to maas 2.0 cloud with juju 2.0 beta 7 <juju-core:New> <https://launchpad.net/bugs/1585857>03:52
wallyworldaxw: as per roger's suggestion, i added extra tests and improved the marshalling https://github.com/juju/charm/pull/21004:00
axwwallyworld: LGTM04:03
wallyworldty04:03
wallyworldaxw: small one, https://github.com/juju/idmclient/pull/1704:20
wallyworldthere's sooooo many :-(04:21
=== redir is now known as redir_afk
wallyworldaxw: idmclient just uses UserTag so v1 and v2 are the same in that respect04:56
axwwallyworld: I was thinking more that names types might exposed in the idmclient API, but it seems not04:57
axwwallyworld: shipit04:57
wallyworldta04:57
=== urulama|swap is now known as urulama
mupBug #1585878 opened: It does not remove the DHCP and DNS configurations on MAAS after juju removes LXD container(machine). <juju-core:New> <https://launchpad.net/bugs/1585878>05:53
mupBug #1585878 changed: It does not remove the DHCP and DNS configurations on MAAS after juju removes LXD container(machine). <MAAS:New> <https://launchpad.net/bugs/1585878>06:29
mupBug #1585878 opened: It does not remove the DHCP and DNS configurations on MAAS after juju removes LXD container(machine). <MAAS:New> <https://launchpad.net/bugs/1585878>06:38
wallyworldaxw: do you have time to talk?06:44
axwwallyworld: yes, but gotta go in ~15m to pick up charlotte06:44
wallyworldok, 1:106:44
wallyworldaxw: google hates me, be there in a sec06:45
mupBug #1585878 changed: It does not remove the DHCP and DNS configurations on MAAS after juju removes LXD container(machine). <MAAS:New> <https://launchpad.net/bugs/1585878>06:53
mupBug #1585878 opened: Removing a container does not remove the underlying MAAS device representing the container unless the host is also removed. <juju-core:Triaged> <https://launchpad.net/bugs/1585878>07:17
=== frankban|afk is now known as frankban
=== frankban is now known as frankban|afk
=== frankban|afk is now known as frankban
babbageclunkfrobware: 1:1?08:31
frobwarebabbageclunk: yep, sent link via PM08:32
frobwaredimitern, dooferlad: standup09:02
dooferladfrobware: just booking some passport stuff. There soon.09:02
frobwaredooferlad: k09:02
=== akhavr1 is now known as akhavr
hoenirhttp://reviews.vapour.ws/r/4900/ can anyone have another look on this PR? it fixes this https://bugs.launchpad.net/juju-core/+bug/158543010:19
mupBug #1585430: Cloud-init failed on windows <ci> <cloudbase-init> <format> <regression> <windows> <juju-core:In Progress by sgiulitti> <https://launchpad.net/bugs/1585430>10:19
voidspacefwereade: ping10:23
fwereadevoidspace, pong11:44
mupBug #1585857 changed: Unable to add credential to maas cloud with juju 2.0 beta 7 <hs-arm64> <juju-core:New> <https://launchpad.net/bugs/1585857>12:06
mupBug #1586007 opened: cannot ssh to LXD container on non MAAS systems using juju ssh --proxy 0/lxd/0 <juju-core:New> <https://launchpad.net/bugs/1586007>12:06
voidspacefwereade: philosophy question about model migration12:06
voidspacefwereade: will we assume data integrity - i.e. referred to entities exist - or should we import entities in the right order (any circular references will be a problem) and verify during import12:07
voidspacefwereade: i.e. addresses reference devices (amongst other things) - must we import the devices first and check when we import the addresses12:07
voidspacefwereade: or is it ok to assume data integrity (the device must have existed for the address to be created)12:07
voidspacefwereade: without checks the new model will only be as screwed as the old model12:08
voidspacefwereade: with checks we may refuse to import at all12:08
fwereadevoidspace, my understanding is that we validate the model both source-side and dest-side12:14
voidspacefwereade: so we need to ensure we do the imports in the right order12:14
fwereadevoidspace, if either side fails we can't migrate but we can at least unfreeze the model in the source controller and keep it going12:14
voidspacefwereade: and to do the checks the imports need to be implemented in the right order12:15
fwereadevoidspace, I'm not sure we do? the interface seems to me like it's tuned for just setting lots of things and then validating the whole lot at the end12:15
fwereadevoidspace, so source validates before sending; target validates before applying; failure at any stage, including application, should roll back the whole thing12:16
fwereadevoidspace, we only drop the model from the source when everything's confirmed it's happily talking to the target controller12:16
voidspacefwereade: certainly a validation step could be added12:17
voidspacefwereade: I don't *see* it here though: https://docs.google.com/document/d/1HVWgLxV3CJWI-IAzb2NvFOxhkx4Q3qsePxQ9-F2ZYIE/edit#12:17
fwereadevoidspace, core/description.Model has a Validate method12:19
voidspacefwereade: ah, indeed it does12:20
fwereadevoidspace, I don't think of validation as a separate step so much as something you Just Do when data crosses a boundary12:20
fwereadevoidspace, definitely on the way in, plausibly on the way out as well at times12:20
voidspacefwereade: the examples I was following for implementation didn't need any validation so didn't include anything here12:21
voidspacefwereade: ok, so some additional work needed here12:21
fwereadevoidspace, I'm not really familiar with the nuts and bolts of the validation, I'm afraid12:21
voidspacefwereade: cool, you answered my question anyway12:22
voidspacefwereade: appreciated12:22
frobwarecherylj: ok to merge http://reviews.vapour.ws/r/4903/ ?13:03
frobwaredooferlad: ping13:28
dooferladfrobware: pong13:30
frobwaredooferlad: having trouble with your bridge script changes - can we HO?13:30
dooferladfrobware: sure13:32
dooferladfrobware: juju-sapphire?13:32
frobwareyep13:32
babbageclunkvoidspace: ping?13:48
mupBug #1518806 changed: apiserver: tests to not pass with -race under Go 1.2 <2.0-count> <juju-core:Fix Released by dave-cheney> <https://launchpad.net/bugs/1518806>13:51
mupBug #1519133 changed: cmd/jujud/agent: data race <2.0-count> <juju-core:Fix Released by dave-cheney> <https://launchpad.net/bugs/1519133>13:51
mupBug #1519191 changed: worker/addresser: FAIL: worker_test.go:260: workerEnabledSuite.TestWorkerAcceptsBrokenRelease <2.0-count> <juju-core:Fix Released by dave-cheney> <https://launchpad.net/bugs/1519191>13:51
cheryljfrobware: yes, go ahead and merge13:51
babbageclunkdimitern: ping?14:08
dimiternbabbageclunk: pong14:08
babbageclunkdimitern: I'm trying to debug a flaky test I'm hitting.14:09
babbageclunkIt's this: https://github.com/juju/juju/blob/master/state/subnets_test.go#L42414:10
babbageclunkdimitern: (asking you because voidspace didn't respond)14:10
dimiternbabbageclunk: let me have a look..14:10
dimiternbabbageclunk: I don't think it's flaky14:11
babbageclunkdimitern: It looks like the patch there isn't working - the code doesn't use the patched name, so it's calling the original function and just happening to pass.14:11
babbageclunkdimitern: It is on 3.2 with my changes ;)14:11
dimiternbabbageclunk: yeah, the way PatchValue is used might cause it to be though..14:12
babbageclunkdimitern: which might be my fault, but I'm trying to understand what's happening.14:12
dimiternbabbageclunk: have a look at the internals of PatchValue - there are 2 slices of patched stuff - suite-level and test-level14:12
babbageclunkdimitern: But in the code https://github.com/juju/juju/blob/master/state/subnets.go#L330 it uses the lowercase name, so it looks like it always uses the unpatched function14:13
babbageclunk(Also I put in some logging and verified that.)14:13
dimiternbabbageclunk: oh ..14:14
dimiternbabbageclunk: the real pickAddress is non-deterministic14:14
dimiternbabbageclunk: as it picks random addresses from the subnet range14:14
babbageclunkdimitern: So I think the test has been passing by accident.14:15
dimiternbabbageclunk: I suspect the way it's patched is wrong14:15
dimiternbabbageclunk: e.g. I'd expect to see something like s.PatchValue(&state.Foo, func(matching-args-decls) { ... })14:16
babbageclunkdimitern: Well, the test is in a different package, so I don't think it can patch the lowercase name.14:16
dimiternbabbageclunk: i.e. &mockPickAddress looks wrong14:16
dimiternbabbageclunk: depends how state.PickAddress is exported14:17
babbageclunkOk - so you think it's the & that's wrong, rather than the naming?14:17
dimiternbabbageclunk: for funcs, it's quite common to use var Foo = &foo in export_test, then s.PatchValue(pkg.Foo, func (...) { .. })14:18
dimiternbabbageclunk: naming is fine - it looks weird, but because of export_test.go (btw such things cannot be followed with godef as well)14:18
dimiternbabbageclunk: OTOH, you have var Foo = foo in export_test of package pkg, &pkg.Foo in pkg_test points to the pkg.Foo var in export_test, NOT to the pkg.foo14:20
lazyPowerping natefinch14:21
babbageclunkdimitern: Ok, I think I follow - I'll try changing export_test to make it work.14:21
dimiternbabbageclunk: that is important for patching functions, not so much for simple vars (e.g. exposing struct foo{unexp. fields..})14:23
dimiternbabbageclunk: +114:24
mupBug #1580186 changed: Race in github.com/juju/juju/worker/instancepoller/aggregate_test.go <ci> <intermittent-failure> <race-condition> <regression> <unit-tests> <juju-core:Fix Released by reedobrien> <https://launchpad.net/bugs/1580186>14:24
mupBug #1585430 changed: Cloud-init failed on windows <blocker> <ci> <cloudbase-init> <format> <regression> <windows> <juju-core:Fix Released by sgiulitti> <https://launchpad.net/bugs/1585430>14:24
mupBug #1585856 changed: worker/txnpruner: test failure during ci <juju-core:New> <https://launchpad.net/bugs/1585856>14:24
mupBug #1586057 opened: Race in github.com/juju/juju/container/lxc <ci> <lxc> <race-condition> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1586057>14:24
frobwaredimitern, jam: were we going to talk about fan/networking today?14:25
dimiternfrobware: we still can :)14:29
voidspacebabbageclunk: sorry, was on lunch14:44
babbageclunkvoidspace: No worries. Picked dimitern's brains instead, although I'm still a bit stuck14:45
voidspacebabbageclunk: yeah, read the backscroll14:46
babbageclunkvoidspace: can you see what's wrong with the patching? Is it possible to do that from outside the package if the code's calling the lowercase name?14:47
voidspacebabbageclunk: no, the code should call the name that's being patched14:47
babbageclunkSo maybe I should change subnets.go to assign PickAddress (and call it) and  remove the alias from export_test?14:49
voidspacebabbageclunk: the alias is needed to allow patching14:50
voidspacebabbageclunk: without an alias it can't be patched14:51
voidspacebabbageclunk: are you suggesting removing the patching (which doesn't do anything) as well?14:51
babbageclunkvoidspace: I thought the alias was to make it visible from outside the package.14:51
voidspacebabbageclunk: you can't patch a function directly - however if you create a pointer alias you can patch *that*14:52
babbageclunkvoidspace: no - the test needs the patch, otherwise it randomly fails.14:52
voidspacebabbageclunk: so just change the code to call the upper case version (the patched one)14:52
babbageclunkvoidspace: pickAddress is defined as var pickAddress = func in subnets.go.14:53
babbageclunkvoidspace: But the uppercase one only exists in exports_test.go14:53
voidspacebabbageclunk: hmm...14:53
babbageclunkvoidspace: (sorry, export_test.go)14:53
voidspacebabbageclunk: so an uppercase alias in export_test is usually for testing an unexported function14:54
voidspacebabbageclunk: and a function created as var *can* be patched, but if it's lower case then only from within the package - not from a black box test14:54
mupBug #1585430 opened: Cloud-init failed on windows <blocker> <ci> <cloudbase-init> <format> <regression> <windows> <juju-core:Fix Committed by sgiulitti> <https://launchpad.net/bugs/1585430>14:54
babbageclunkvoidspace: So I couldn't rebind a function defined as an uppercase var from outside the package? (As I type that it sounds like a bad idea even if possible.)14:56
babbageclunkvoidspace: turns out that *does* work - the patched function now gets called. But it still sometimes fail for reasons I've not yet worked out.14:58
voidspacebabbageclunk: ok, that sounds like the right thing to do for this test14:58
voidspacebabbageclunk: now work out why it fails and fix it :-)14:58
babbageclunkvoidspace: Maybe I should have done that in the first place. :)14:59
voidspacebabbageclunk: hah14:59
babbageclunkvoidspace: The first thing I did was get confused about why my added logging wasn't showing up.14:59
voidspacebabbageclunk: why wasn't it?15:04
babbageclunkvoidspace: because I added it to mockPickAddress, which wasn't being called.15:05
voidspaceah!15:06
cmarshey, is there a mongodb 3.2 in the ubuntu archives? i noticed that we're using it for the controller now.. is there a ppa where i can apt install it from too?15:10
frobwarecherylj: fyi - https://bugs.launchpad.net/maas/+bug/158607515:11
mupBug #1586075: Deploying a trusty node on MAAS 1.9.3 gives us 2 entries for eth0 in /e/n/i <juju> <MAAS:New> <https://launchpad.net/bugs/1586075>15:11
* katco needs to reboot15:43
alexisbfrobware, dimitern, just sent a note, take a look and let me know15:44
frobwarealexisb: looking15:45
dimiternalexisb: sure15:46
dimiternalexisb: replied15:55
alexisbdimitern, thanks15:55
natefinchfwereade: you around?16:16
mupBug #1586089 opened: azure arm instance-ids are not ids, cannot find machine in azure <azure-provider> <ci> <ha> <jujuqa> <testing> <juju-core:Triaged> <https://launchpad.net/bugs/1586089>16:18
=== frankban is now known as frankban|afk
babbageclunkperrito666: ping?16:47
perrito666babbageclunk: pong16:47
babbageclunkperrito666: I'm just trying to finish up these mongo3.2 changes...16:48
babbageclunkperrito666: but I've hit a couple of places where 3.2 behaves a bit oddly16:49
perrito666babbageclunk: ok, tell me, how can I help you?16:49
babbageclunkperrito666: (Happy birthday for yesterday by the way!)16:49
perrito666babbageclunk: tx :)16:49
babbageclunkperrito666: one of them is in OplogTailer16:50
perrito666mh, I am not familiar with it16:51
babbageclunkperrito666: Doh, I thought I saw your name on it, sorry!16:51
perrito666babbageclunk: I might have passed by changing something16:52
perrito666but I am pretty sure its one of menn0's16:52
babbageclunkperrito666: yup, you're right16:53
perrito666sorry that was not helpful :(16:53
babbageclunkperrito666: Well, I'll bug him about this instead! Sorry!16:54
babbageclunkperrito666: :)16:54
frobwarevoidspace, dimitern, babbageclunk, dooferlad: anybody done $(juju add-machine lxd:0) on trusty recently, bootstrapping on MAAS?17:01
dimiternfrobware: not in a few days17:01
babbageclunkfrobware: nope, just mongo bashing17:01
frobwaredimitern: I don't seem to have backports enabled in trusty any more17:01
dimiternfrobware: did you update the images?17:02
frobwarehttps://bugs.launchpad.net/juju-core/+bug/156889517:02
mupBug #1568895: Cannot add MAAS-based LXD containers in 2.0beta4 on trusty <ci> <jujuqa> <lxd> <maas-provider> <cloud-images:Fix Released> <juju-core:Fix Released> <https://launchpad.net/bugs/1568895>17:02
frobwaredimitern: my maas setup says "last update:Thu, 26 May. 2016 17:45:03"17:03
frobwaredimitern: are you in a position to run a lxd container at all?17:03
frobwarebabbageclunk, dooferlad, voidspace ^^17:04
dimiternfrobware: let me do a quick test locally..17:05
dimiternfrobware: uh oh.. it failed to deploy at all.. I was messing with LVM groups and volumes to try to simulate having 2 disks to deploy OS17:16
frobwaredimitern: so unrelated failures?17:16
dimiternfrobware: I'm trying again to verify..17:17
frobwaredimitern: ok, also trying on my laptop which still has maas-1.9.217:17
frobwaredimitern: though I don't think that's the issue at all17:18
dimiternfrobware: ok, now it got deployed, adding lxd:017:18
frobwaredimitern: in theory you shouldn't need juju17:20
frobwaredimitern: just deploy a node17:20
frobwaredimitern: you only need to verify the content of /e/apt/sources.list17:20
dimiternfrobware: no backports here17:21
frobwaredimitern: I think this is bust again. Let me update the bug. Could you do so too.17:21
dimiternE: The value 'trusty-backports' is invalid for APT::Default-Release as such a release is not available in the sources17:21
frobwaredimitern: sigh. that was a waste of a few hours.17:23
frobwaredimitern: sometimes it feels hard to make progress. :(17:23
frobwaredimitern: I'm surprisd this is not showing up in CI tests17:24
frobwaresinzui: ^^17:24
dimiternfrobware: updated the bug (I assume you meant 1569985?)17:26
dimiternoops not that - 156889517:26
frobwaredimitern: yep17:26
sinzuifrobware. I think we have seen it., but is is not a current issue17:26
sinzuifrobware: bug 1556137 mentions it17:27
mupBug #1556137: Juju 2.0: cannot connect to LXC container when deploying bundle with LXC container placement with maas 1.9.1 as provider <2.0-count> <oil> <juju-core:Triaged> <MAAS:New> <https://launchpad.net/bugs/1556137>17:27
frobwaresinzui: ooh, I now why that one is broken17:28
mupBug #1585430 changed: Cloud-init failed on windows <blocker> <ci> <cloudbase-init> <format> <regression> <windows> <juju-core:Fix Released by sgiulitti> <https://launchpad.net/bugs/1585430>17:28
mupBug #1586116 opened: GCE bootstraps but fails to provision <gce-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1586116>17:28
frobwaresinzui: ah, sorry, nope. I was actually thinking of: https://bugs.launchpad.net/juju-core/+bug/1576674/  Sorry for the noise17:30
mupBug #1576674: 2.0 beta6: only able to access LXD containers (on maas deployed host) from the maas network <lxd> <maas-provider> <oil> <ssh> <juju-core:Triaged> <https://launchpad.net/bugs/1576674>17:30
dimiternfrobware: if you're still about for a short while, I'm finally proposing a fix for the IPv6 bug17:31
frobwaredimitern: I can be17:31
dimitern(take 3, totally rethought and as simple as possible)17:31
frobwaredimitern: let's stop at 11. :)17:31
dimiternfrobware: good plan :)17:34
dimiternfrobware:http://reviews.vapour.ws/r/4915/17:35
frobwaredimitern: looking but will mostly try first.17:35
dimiternfrobware: +117:35
frobwaredimitern:  for a repro, just deploy 20 units?17:36
dimiternfrobware: yeah - less than 20 should still work17:36
dimiternfrobware: ah! important: make sure your lxdbr0 is configured to give *both* ipv4 and ipv6 addresses17:37
frobwaresinzui: what's the correct status for reopening a bug? mark as "confirmed" again? Just want to ensure bug #1568895 get some other eyes verifying current status17:38
mupBug #1568895: Cannot add MAAS-based LXD containers in 2.0beta4 on trusty <ci> <jujuqa> <lxd> <maas-provider> <cloud-images:Fix Released> <juju-core:Fix Released> <https://launchpad.net/bugs/1568895>17:38
frobwaredimitern: does it matter which series I should use?17:38
sinzuifrobware: if you have the power, mark it triaged, otherwise confirmed17:38
sinzuifrobware: it does matter if the issue is not in master17:39
frobwaresinzui: seems more likely to be outside of juju17:39
dimiternfrobware: I used xenial, but shouldn't matter really17:40
dimiternfrobware: actually a couple of days I also tested with trusty (the earlier fix)17:40
frobwaredimitern: but not with containers17:41
sinzuifrobware: about trusty-backports. Old images do not have them enabled. backports were enabled by default in xenial images. trusty imagages were updated and released to the clouds a few months ago17:41
frobwaresinzui: but I did go through a stage where a trusty MAAS node had backports enabled.17:42
sinzuifrobware: I expect newish trusty images to have trusty-backports enabled. The maas images are made by the team that make cloud-images17:45
frobwaresinzui: but wasn't this previously failing in CI, then confirmed as working once the images had been updated.17:46
perrito666bbl17:48
* natefinch is a team of one, evidently.18:06
redirgo team nate18:06
redirgo team natefinch even18:06
natefinch:)18:06
redirrah rah ree kick em in the knee18:07
mupBug #1568895 opened: Cannot add MAAS-based LXD containers in 2.0beta4 on trusty <ci> <jujuqa> <lxd> <maas-provider> <cloud-images:Confirmed> <juju-core:Confirmed> <https://launchpad.net/bugs/1568895>18:07
natefinchI guess we're not having the team meeting today?  Now that we only have managers that are asleep at this time, having a team meeting seems silly18:07
redirbbiab18:53
natefinchalexisb:19:04
mupBug #1586150 opened: destroy-model does not remove the model <cdo-qa> <destroy-model> <juju-core:New> <https://launchpad.net/bugs/1586150>19:34
mupBug #1586150 changed: destroy-model does not remove the model <cdo-qa> <destroy-model> <juju-core:New> <https://launchpad.net/bugs/1586150>19:46
mupBug #1586150 opened: destroy-model does not remove the model <cdo-qa> <destroy-model> <juju-core:New> <https://launchpad.net/bugs/1586150>19:55
mupBug #1586150 changed: destroy-model does not remove the model <cdo-qa> <destroy-model> <juju-core:New> <https://launchpad.net/bugs/1586150>20:49
arosalesnatefinch: katco: jsut as a heads up, if you have some time could you take a look at https://github.com/juju/docs/pull/112220:56
arosaleswe need to get terms docs to users to so they can start prepping their charms for GA20:57
arosales2.0 ga, that is20:57
arosalesmbruzek: ^20:57
rick_h_arosales: ty, wil try to hook up cmars and his team with the docs folks as they did terms21:09
cmarsrick_h_, arosales https://github.com/juju/docs/blob/master/src/en/developer-terms.md21:11
rick_h_cmars: <321:11
arosalescmars: :-) so those land and I already referenced them on the list :-)21:13
arosaless/so/saw/21:14
arosalessorry earlier I meant to say resources we need a review on21:15
arosalesper https://github.com/juju/docs/pull/112221:15
arosalesI think mbruzek was looking for a final ack from katco and natefinch21:15
arosalesfor resources on terms21:15
cheryljalexisb: release standup?21:33
=== meetingology` is now known as meetingology
cheryljtych0: ping?21:56
mupBug #1585851 changed: Cannot restore-backup of controller model <backup-restore> <blocker> <ci> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1585851>22:11
babbageclunkhey menn0!22:14
menn0babbageclunk: hey hey!22:15
babbageclunkmenn0: happy birthday for yesterday!22:19
babbageclunkmenn0: Have you got a moment for a quick q?22:19
menn0babbageclunk: cheers22:19
menn0babbageclunk: sure22:19
babbageclunkmenn0: I'm trying to get the full test suite passing with Mongo 3.2...22:20
babbageclunkmenn0: But there are a couple of places where we get different errors now than we used to.22:21
babbageclunkmenn0: *sometimes*22:21
babbageclunkmenn0: So they make the tests flaky.22:21
menn0babbageclunk: that sounds fun :-/22:22
babbageclunkmenn0: Well, it's a bit suboptimal.22:22
menn0babbageclunk: do you mean that for the same root cause mongodb returns different errors at times?22:22
babbageclunkmenn0: Yeah - for example:22:22
babbageclunkhttps://github.com/babbageclunk/juju/commit/61da79e198d15263579f717da21e0e5925da0f3b22:23
babbageclunkmenn0: Instead of a nice mgo.ErrCursor, we sometimes get a generic mgo.QueryError22:24
menn0babbageclunk: ah right... I even know about that one. https://bugs.launchpad.net/juju-core/+bug/157328622:24
mupBug #1573286: juju/mongo: oplog tests fail with mongod 3.2 <mongodb> <unit-tests> <juju-core:Triaged by menno.smits> <https://launchpad.net/bugs/1573286>22:24
babbageclunkmenn0: Ha!22:25
babbageclunkmenn0: Ok, hadn't seen that.22:25
menn0babbageclunk: mwhudson created that ticket when he first ran into this22:25
menn0and told me about it22:25
alexisbwallyworld, menn0, cherylj, sinzui, rick_h_, I need some of your time i fyou are available22:25
menn0babbageclunk: I haven't put any thought into it yet22:26
menn0alexisb: i'm around22:26
wallyworldalexisb: ok22:26
alexisbhttps://plus.google.com/hangouts/_/canonical.com/juju-release22:26
mwhudsonbabbageclunk: wow, that general task is one hell of a welcome to the job22:26
alexisbmwhudson, yes yes it is22:26
menn0babbageclunk: let me have a think about that particular issue ... have to jump on this call22:27
menn0alexisb, mwhudson: luckily babbageclunk is a smart cookie :)22:27
babbageclunkmenn0: Yeah - I'm not sure whether my fix is good - it's essentially only happpening during the tests, so it seems odd to handle it in the prod code.22:27
babbageclunkmenn0: Ok, talk later.22:27
mwhudsonmenn0, alexisb: that's ok then :-)22:27
* babbageclunk blushes.22:27
babbageclunkmwhudson: It seemed ok at first!22:29
mwhudsonbabbageclunk: that's a good sign, i guess :)22:30
babbageclunkmwhudson: I feel like it's *just this last bit*, but I've thought that for about 4 days now. :)22:31
mwhudsonbabbageclunk: heh22:31
mwhudsonbabbageclunk: did you beat the state tests into submission?22:32
mwhudsonthat seemed like the worst bit22:32
babbageclunkmwhudson: Yeah, that 100x slowdown is crazy!22:32
babbageclunkmwhudson: I mean, I've hacked around it, mostly (although they still run slower than with 2.4).22:33
mwhudsonbabbageclunk: oh yes, i saw something about that, emptying the db rather than recreating it?22:34
babbageclunkmwhudson: yuo22:34
babbageclunkuh, yup22:34
mwhudsonbabbageclunk: i also saw something running out of file descriptors sometimes, you've not hit that?22:34
babbageclunkmwhudson: No...22:34
mwhudsonwell good, i guess :)22:35
babbageclunkmwhudson: I saw your mention of it, but it's not happened to me.22:35
babbageclunkmwhudson: good unless it starts happening in builds I guess.22:35
mwhudsonheh yes22:35
babbageclunkmwhudson: Right, I have to go sleep. Nice to meet you!22:37
mwhudsonbabbageclunk: good night!22:37
mupBug #1585851 opened: Cannot restore-backup of controller model <backup-restore> <blocker> <ci> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1585851>22:44
davechen1yci builds are failing because gopkg.in is unwell22:46
anastasiamac_davechen1y: see #juju22:48
anastasiamac_davechen1y: sinzui is onto it \o/ but landing is paused for now...22:49
menn0babbageclunk: i'm off the call now... what was your fix for the oplog test problem?22:55
babbageclunkmenn0: I just in some code to check for the specific QueryError I was seeing, which is hacky but ok (I think).22:56
babbageclunkmenn0: It's really the other one that's giving me pause - sending you an email 'cause I really need to go to bed.22:57
babbageclunkmenn0: It turns out toddlers don't stay in bed later just because you got another baby!22:58
menn0babbageclunk: ok no problems. sleep is good :) i'll take a look at this today22:58
babbageclunkmenn0: Who knew?22:58
menn0babbageclunk: yep :) Sander gets up and into our bed about 5:30am every day. Amelia sleeps in most days at least23:01
babbageclunkmenn0: Say hi to the family! Night.23:02
menn0babbageclunk: goodnight!23:02
mupBug #1586197 opened: Upgrade to 1.25.5 not possible, due to cannot store tools metadata: invalid binary version \"1.25.5--amd64\" <sts-needs-review> <juju-core:New> <https://launchpad.net/bugs/1586197>23:23

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