[00:37] <davechen1y> ping alexisb
[00:38] <alexisb> heya davechen1y
[00:38] <alexisb> whats up?
[00:38] <davechen1y> alexisb: i just sent you an email that requires acknowledgement
[00:38] <davechen1y> it's very short, could you please read and respond
[00:38] <davechen1y> thanks
[00:38] <alexisb> davechen1y, will do
[00:39] <davechen1y> thanks
[00:41] <alexisb> davechen1y, responded
[00:41] <davechen1y> alexisb: ta
[00:45] <davechen1y> ok, next question
[00:45] <davechen1y> JFDI or not JFDI
[00:45] <davechen1y> i have a PR that is at the bottom of a lot of blocked bugs for beta8
[00:45] <davechen1y> can I JFDI ?
[00:47] <anastasiamac_> davechen1y: is it blocker? u can't just use $$fixes-blah$$?
[00:49] <davechen1y> anastasiamac_: i don't know
[00:49] <davechen1y> the issue i am assigned is not the one that is blocking landing
[00:49] <anastasiamac_> ic. is it the race fix?
[00:50] <davechen1y> yes
[00:50] <davechen1y> well
[00:50] <davechen1y> maybe
[00:50] <davechen1y> this is not the issue that CI is blocked o
[00:50] <davechen1y> on
[00:51] <anastasiamac_> so u r right, plz do not JFDI unless u have an explicit "please land" from alexisb or cherylj or sinzui
[00:51] <davechen1y> ok, i've marked my PR as blcoked on the landing bot and i'll work on something else
[00:51] <anastasiamac_> \o/
[00:52] <davechen1y> how can I find out when this build was run http://reports.vapour.ws/releases/3993/job/run-unit-tests-race/attempt/1495
[00:52] <davechen1y> this is the last race build that was run
[00:52] <davechen1y> i require the CI rae infrastructure to validate the fixes I am landing
[00:52] <davechen1y> is the ci race build running currently ?
[00:54] <sinzui> davechen1y: follow the link to the build number in the top nav. http://reports.vapour.ws/releases/3993  Wed May 25 08:59:46 2016
[00:54] <davechen1y> i get a 404
[00:54] <davechen1y> when I follow that link
[00:55] <davechen1y> sorry, i get a 404 when I follow the link to the jenkins job
[00:55] <sinzui> davechen1y: are you no longer a member oc canonical?
[00:55] <davechen1y> sinzui: one can only hope
[00:55] <sinzui> davechen1y: jenkins jobs only last a few days. All the data is on the reports site
[00:56] <davechen1y> sinzui: so does that mean the race job has not run for at least a few days ?
[00:56] <davechen1y> run-unit-tests-race1495Bug #1579051
[00:56] <mup> Bug #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 release
[00:56] <sinzui> davechen1y: no. the job is run with every revision
[00:57] <davechen1y> sinzui: that doesn't make sense
[00:57] <davechen1y> if run-unit-tests-race 1495 was run recently, as in since last night then the jenkins job would be 404
[00:57] <davechen1y> wouldn't be 404
[00:57] <sinzui> davechen1y: 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:58] <davechen1y> sinzui: i dont' have a login for that site
[00:58] <davechen1y> or chrome has forgotten them :(
[01:10] <mup> Bug #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:22] <mup> Bug #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:28] <mup> Bug #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] <mup> Bug #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:29] <wallyworld> axw: a small one when you are free http://reviews.vapour.ws/r/4905/
[01:31] <mup> Bug #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] <axw> wallyworld: what changed the error message change?
[01:32] <wallyworld> axw: new dep i suspect
[01:32] <wallyworld> httprequest maybe
[01:32] <axw> wallyworld: that function just uses net/http AFAICS
[01:34] <wallyworld> axw: 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 deps
[01:34] <axw> wallyworld: please do, doesn't look related to me
[01:34] <wallyworld> ok, otp will do soon
[01:35]  * redir goes eod
[01:40] <mup> Bug #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>
[02:37] <axw> wallyworld: I see you reverted, did you get to the bottom of it?
[02:38] <wallyworld> axw: nope, master failed in the same way, nfi
[02:40] <mup> Bug #1585846 opened: worker/terminationworker: test timeout after 20 minutes <juju-core:New> <https://launchpad.net/bugs/1585846>
[02:40] <mup> Bug #1585847 opened: LXD creates all the interfaces as the physical machine has when using MAAS. <juju-core:New> <https://launchpad.net/bugs/1585847>
[02:48] <wallyworld> axw: you happy to +1 with that error message reverted?
[02:48] <axw> wallyworld: yep, will do
[02:48] <wallyworld> ta
[02:49] <axw> wallyworld: done
[02:49] <wallyworld> ty
[03:10] <mup> Bug #1585849 opened: Azure native bundle 404 creating resources <azure-provider> <bundle> <ci> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1585849>
[03:10] <mup> Bug #1585851 opened: Cannot restore-backup of controller model <backup-restore> <ci> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1585851>
[03:31] <mup> Bug #1585856 opened: worker/txnpruner: test failure during ci <juju-core:New> <https://launchpad.net/bugs/1585856>
[03:52] <mup> Bug #1585857 opened: Unable to bootstrap to maas 2.0 cloud with juju 2.0 beta 7 <juju-core:New> <https://launchpad.net/bugs/1585857>
[04:00] <wallyworld> axw: as per roger's suggestion, i added extra tests and improved the marshalling https://github.com/juju/charm/pull/210
[04:03] <axw> wallyworld: LGTM
[04:03] <wallyworld> ty
[04:20] <wallyworld> axw: small one, https://github.com/juju/idmclient/pull/17
[04:21] <wallyworld> there's sooooo many :-(
[04:56] <wallyworld> axw: idmclient just uses UserTag so v1 and v2 are the same in that respect
[04:57] <axw> wallyworld: I was thinking more that names types might exposed in the idmclient API, but it seems not
[04:57] <axw> wallyworld: shipit
[04:57] <wallyworld> ta
[05:53] <mup> Bug #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>
[06:29] <mup> Bug #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:38] <mup> Bug #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:44] <wallyworld> axw: do you have time to talk?
[06:44] <axw> wallyworld: yes, but gotta go in ~15m to pick up charlotte
[06:44] <wallyworld> ok, 1:1
[06:45] <wallyworld> axw: google hates me, be there in a sec
[06:53] <mup> Bug #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>
[07:17] <mup> Bug #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>
[08:31] <babbageclunk> frobware: 1:1?
[08:32] <frobware> babbageclunk: yep, sent link via PM
[09:02] <frobware> dimitern, dooferlad: standup
[09:02] <dooferlad> frobware: just booking some passport stuff. There soon.
[09:02] <frobware> dooferlad: k
[10:19] <hoenir> http://reviews.vapour.ws/r/4900/ can anyone have another look on this PR? it fixes this https://bugs.launchpad.net/juju-core/+bug/1585430
[10:19] <mup> Bug #1585430: Cloud-init failed on windows <ci> <cloudbase-init> <format> <regression> <windows> <juju-core:In Progress by sgiulitti> <https://launchpad.net/bugs/1585430>
[10:23] <voidspace> fwereade: ping
[11:44] <fwereade> voidspace, pong
[12:06] <mup> Bug #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] <mup> Bug #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] <voidspace> fwereade: philosophy question about model migration
[12:07] <voidspace> fwereade: 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 import
[12:07] <voidspace> fwereade: i.e. addresses reference devices (amongst other things) - must we import the devices first and check when we import the addresses
[12:07] <voidspace> fwereade: or is it ok to assume data integrity (the device must have existed for the address to be created)
[12:08] <voidspace> fwereade: without checks the new model will only be as screwed as the old model
[12:08] <voidspace> fwereade: with checks we may refuse to import at all
[12:14] <fwereade> voidspace, my understanding is that we validate the model both source-side and dest-side
[12:14] <voidspace> fwereade: so we need to ensure we do the imports in the right order
[12:14] <fwereade> voidspace, if either side fails we can't migrate but we can at least unfreeze the model in the source controller and keep it going
[12:15] <voidspace> fwereade: and to do the checks the imports need to be implemented in the right order
[12:15] <fwereade> voidspace, 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 end
[12:16] <fwereade> voidspace, so source validates before sending; target validates before applying; failure at any stage, including application, should roll back the whole thing
[12:16] <fwereade> voidspace, we only drop the model from the source when everything's confirmed it's happily talking to the target controller
[12:17] <voidspace> fwereade: certainly a validation step could be added
[12:17] <voidspace> fwereade: I don't *see* it here though: https://docs.google.com/document/d/1HVWgLxV3CJWI-IAzb2NvFOxhkx4Q3qsePxQ9-F2ZYIE/edit#
[12:19] <fwereade> voidspace, core/description.Model has a Validate method
[12:20] <voidspace> fwereade: ah, indeed it does
[12:20] <fwereade> voidspace, I don't think of validation as a separate step so much as something you Just Do when data crosses a boundary
[12:20] <fwereade> voidspace, definitely on the way in, plausibly on the way out as well at times
[12:21] <voidspace> fwereade: the examples I was following for implementation didn't need any validation so didn't include anything here
[12:21] <voidspace> fwereade: ok, so some additional work needed here
[12:21] <fwereade> voidspace, I'm not really familiar with the nuts and bolts of the validation, I'm afraid
[12:22] <voidspace> fwereade: cool, you answered my question anyway
[12:22] <voidspace> fwereade: appreciated
[13:03] <frobware> cherylj: ok to merge http://reviews.vapour.ws/r/4903/ ?
[13:28] <frobware> dooferlad: ping
[13:30] <dooferlad> frobware: pong
[13:30] <frobware> dooferlad: having trouble with your bridge script changes - can we HO?
[13:32] <dooferlad> frobware: sure
[13:32] <dooferlad> frobware: juju-sapphire?
[13:32] <frobware> yep
[13:48] <babbageclunk> voidspace: ping?
[13:51] <mup> Bug #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] <mup> Bug #1519133 changed: cmd/jujud/agent: data race <2.0-count> <juju-core:Fix Released by dave-cheney> <https://launchpad.net/bugs/1519133>
[13:51] <mup> Bug #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] <cherylj> frobware: yes, go ahead and merge
[14:08] <babbageclunk> dimitern: ping?
[14:08] <dimitern> babbageclunk: pong
[14:09] <babbageclunk> dimitern: I'm trying to debug a flaky test I'm hitting.
[14:10] <babbageclunk> It's this: https://github.com/juju/juju/blob/master/state/subnets_test.go#L424
[14:10] <babbageclunk> dimitern: (asking you because voidspace didn't respond)
[14:10] <dimitern> babbageclunk: let me have a look..
[14:11] <dimitern> babbageclunk: I don't think it's flaky
[14:11] <babbageclunk> dimitern: 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] <babbageclunk> dimitern: It is on 3.2 with my changes ;)
[14:12] <dimitern> babbageclunk: yeah, the way PatchValue is used might cause it to be though..
[14:12] <babbageclunk> dimitern: which might be my fault, but I'm trying to understand what's happening.
[14:12] <dimitern> babbageclunk: have a look at the internals of PatchValue - there are 2 slices of patched stuff - suite-level and test-level
[14:13] <babbageclunk> dimitern: 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 function
[14:13] <babbageclunk> (Also I put in some logging and verified that.)
[14:14] <dimitern> babbageclunk: oh ..
[14:14] <dimitern> babbageclunk: the real pickAddress is non-deterministic
[14:14] <dimitern> babbageclunk: as it picks random addresses from the subnet range
[14:15] <babbageclunk> dimitern: So I think the test has been passing by accident.
[14:15] <dimitern> babbageclunk: I suspect the way it's patched is wrong
[14:16] <dimitern> babbageclunk: e.g. I'd expect to see something like s.PatchValue(&state.Foo, func(matching-args-decls) { ... })
[14:16] <babbageclunk> dimitern: Well, the test is in a different package, so I don't think it can patch the lowercase name.
[14:16] <dimitern> babbageclunk: i.e. &mockPickAddress looks wrong
[14:17] <dimitern> babbageclunk: depends how state.PickAddress is exported
[14:17] <babbageclunk> Ok - so you think it's the & that's wrong, rather than the naming?
[14:18] <dimitern> babbageclunk: for funcs, it's quite common to use var Foo = &foo in export_test, then s.PatchValue(pkg.Foo, func (...) { .. })
[14:18] <dimitern> babbageclunk: naming is fine - it looks weird, but because of export_test.go (btw such things cannot be followed with godef as well)
[14:20] <dimitern> babbageclunk: 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.foo
[14:21] <lazyPower> ping natefinch
[14:21] <babbageclunk> dimitern: Ok, I think I follow - I'll try changing export_test to make it work.
[14:23] <dimitern> babbageclunk: that is important for patching functions, not so much for simple vars (e.g. exposing struct foo{unexp. fields..})
[14:24] <dimitern> babbageclunk: +1
[14:24] <mup> Bug #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] <mup> Bug #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] <mup> Bug #1585856 changed: worker/txnpruner: test failure during ci <juju-core:New> <https://launchpad.net/bugs/1585856>
[14:24] <mup> Bug #1586057 opened: Race in github.com/juju/juju/container/lxc <ci> <lxc> <race-condition> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1586057>
[14:25] <frobware> dimitern, jam: were we going to talk about fan/networking today?
[14:29] <dimitern> frobware: we still can :)
[14:44] <voidspace> babbageclunk: sorry, was on lunch
[14:45] <babbageclunk> voidspace: No worries. Picked dimitern's brains instead, although I'm still a bit stuck
[14:46] <voidspace> babbageclunk: yeah, read the backscroll
[14:47] <babbageclunk> voidspace: 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] <voidspace> babbageclunk: no, the code should call the name that's being patched
[14:49] <babbageclunk> So maybe I should change subnets.go to assign PickAddress (and call it) and  remove the alias from export_test?
[14:50] <voidspace> babbageclunk: the alias is needed to allow patching
[14:51] <voidspace> babbageclunk: without an alias it can't be patched
[14:51] <voidspace> babbageclunk: are you suggesting removing the patching (which doesn't do anything) as well?
[14:51] <babbageclunk> voidspace: I thought the alias was to make it visible from outside the package.
[14:52] <voidspace> babbageclunk: you can't patch a function directly - however if you create a pointer alias you can patch *that*
[14:52] <babbageclunk> voidspace: no - the test needs the patch, otherwise it randomly fails.
[14:52] <voidspace> babbageclunk: so just change the code to call the upper case version (the patched one)
[14:53] <babbageclunk> voidspace: pickAddress is defined as var pickAddress = func in subnets.go.
[14:53] <babbageclunk> voidspace: But the uppercase one only exists in exports_test.go
[14:53] <voidspace> babbageclunk: hmm...
[14:53] <babbageclunk> voidspace: (sorry, export_test.go)
[14:54] <voidspace> babbageclunk: so an uppercase alias in export_test is usually for testing an unexported function
[14:54] <voidspace> babbageclunk: 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 test
[14:54] <mup> Bug #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:56] <babbageclunk> voidspace: 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:58] <babbageclunk> voidspace: 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] <voidspace> babbageclunk: ok, that sounds like the right thing to do for this test
[14:58] <voidspace> babbageclunk: now work out why it fails and fix it :-)
[14:59] <babbageclunk> voidspace: Maybe I should have done that in the first place. :)
[14:59] <voidspace> babbageclunk: hah
[14:59] <babbageclunk> voidspace: The first thing I did was get confused about why my added logging wasn't showing up.
[15:04] <voidspace> babbageclunk: why wasn't it?
[15:05] <babbageclunk> voidspace: because I added it to mockPickAddress, which wasn't being called.
[15:06] <voidspace> ah!
[15:10] <cmars> hey, 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:11] <frobware> cherylj: fyi - https://bugs.launchpad.net/maas/+bug/1586075
[15:11] <mup> Bug #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:43]  * katco needs to reboot
[15:44] <alexisb> frobware, dimitern, just sent a note, take a look and let me know
[15:45] <frobware> alexisb: looking
[15:46] <dimitern> alexisb: sure
[15:55] <dimitern> alexisb: replied
[15:55] <alexisb> dimitern, thanks
[16:16] <natefinch> fwereade: you around?
[16:18] <mup> Bug #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:47] <babbageclunk> perrito666: ping?
[16:47] <perrito666> babbageclunk: pong
[16:48] <babbageclunk> perrito666: I'm just trying to finish up these mongo3.2 changes...
[16:49] <babbageclunk> perrito666: but I've hit a couple of places where 3.2 behaves a bit oddly
[16:49] <perrito666> babbageclunk: ok, tell me, how can I help you?
[16:49] <babbageclunk> perrito666: (Happy birthday for yesterday by the way!)
[16:49] <perrito666> babbageclunk: tx :)
[16:50] <babbageclunk> perrito666: one of them is in OplogTailer
[16:51] <perrito666> mh, I am not familiar with it
[16:51] <babbageclunk> perrito666: Doh, I thought I saw your name on it, sorry!
[16:52] <perrito666> babbageclunk: I might have passed by changing something
[16:52] <perrito666> but I am pretty sure its one of menn0's
[16:53] <babbageclunk> perrito666: yup, you're right
[16:53] <perrito666> sorry that was not helpful :(
[16:54] <babbageclunk> perrito666: Well, I'll bug him about this instead! Sorry!
[16:54] <babbageclunk> perrito666: :)
[17:01] <frobware> voidspace, dimitern, babbageclunk, dooferlad: anybody done $(juju add-machine lxd:0) on trusty recently, bootstrapping on MAAS?
[17:01] <dimitern> frobware: not in a few days
[17:01] <babbageclunk> frobware: nope, just mongo bashing
[17:01] <frobware> dimitern: I don't seem to have backports enabled in trusty any more
[17:02] <dimitern> frobware: did you update the images?
[17:02] <frobware> https://bugs.launchpad.net/juju-core/+bug/1568895
[17:02] <mup> Bug #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:03] <frobware> dimitern: my maas setup says "last update:	Thu, 26 May. 2016 17:45:03"
[17:03] <frobware> dimitern: are you in a position to run a lxd container at all?
[17:04] <frobware> babbageclunk, dooferlad, voidspace ^^
[17:05] <dimitern> frobware: let me do a quick test locally..
[17:16] <dimitern> frobware: 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 OS
[17:16] <frobware> dimitern: so unrelated failures?
[17:17] <dimitern> frobware: I'm trying again to verify..
[17:17] <frobware> dimitern: ok, also trying on my laptop which still has maas-1.9.2
[17:18] <frobware> dimitern: though I don't think that's the issue at all
[17:18] <dimitern> frobware: ok, now it got deployed, adding lxd:0
[17:20] <frobware> dimitern: in theory you shouldn't need juju
[17:20] <frobware> dimitern: just deploy a node
[17:20] <frobware> dimitern: you only need to verify the content of /e/apt/sources.list
[17:21] <dimitern> frobware: no backports here
[17:21] <frobware> dimitern: I think this is bust again. Let me update the bug. Could you do so too.
[17:21] <dimitern> E: The value 'trusty-backports' is invalid for APT::Default-Release as such a release is not available in the sources
[17:23] <frobware> dimitern: sigh. that was a waste of a few hours.
[17:23] <frobware> dimitern: sometimes it feels hard to make progress. :(
[17:24] <frobware> dimitern: I'm surprisd this is not showing up in CI tests
[17:24] <frobware> sinzui: ^^
[17:26] <dimitern> frobware: updated the bug (I assume you meant 1569985?)
[17:26] <dimitern> oops not that - 1568895
[17:26] <frobware> dimitern: yep
[17:26] <sinzui> frobware. I think we have seen it., but is is not a current issue
[17:27] <sinzui> frobware: bug 1556137 mentions it
[17:27] <mup> Bug #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:28] <frobware> sinzui: ooh, I now why that one is broken
[17:28] <mup> Bug #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] <mup> Bug #1586116 opened: GCE bootstraps but fails to provision <gce-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1586116>
[17:30] <frobware> sinzui: ah, sorry, nope. I was actually thinking of: https://bugs.launchpad.net/juju-core/+bug/1576674/  Sorry for the noise
[17:30] <mup> Bug #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:31] <dimitern> frobware: if you're still about for a short while, I'm finally proposing a fix for the IPv6 bug
[17:31] <frobware> dimitern: I can be
[17:31] <dimitern> (take 3, totally rethought and as simple as possible)
[17:31] <frobware> dimitern: let's stop at 11. :)
[17:34] <dimitern> frobware: good plan :)
[17:35] <dimitern> frobware:http://reviews.vapour.ws/r/4915/
[17:35] <frobware> dimitern: looking but will mostly try first.
[17:35] <dimitern> frobware: +1
[17:36] <frobware> dimitern:  for a repro, just deploy 20 units?
[17:36] <dimitern> frobware: yeah - less than 20 should still work
[17:37] <dimitern> frobware: ah! important: make sure your lxdbr0 is configured to give *both* ipv4 and ipv6 addresses
[17:38] <frobware> sinzui: 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 status
[17:38] <mup> Bug #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] <frobware> dimitern: does it matter which series I should use?
[17:38] <sinzui> frobware: if you have the power, mark it triaged, otherwise confirmed
[17:39] <sinzui> frobware: it does matter if the issue is not in master
[17:39] <frobware> sinzui: seems more likely to be outside of juju
[17:40] <dimitern> frobware: I used xenial, but shouldn't matter really
[17:40] <dimitern> frobware: actually a couple of days I also tested with trusty (the earlier fix)
[17:41] <frobware> dimitern: but not with containers
[17:41] <sinzui> frobware: 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 ago
[17:42] <frobware> sinzui: but I did go through a stage where a trusty MAAS node had backports enabled.
[17:45] <sinzui> frobware: I expect newish trusty images to have trusty-backports enabled. The maas images are made by the team that make cloud-images
[17:46] <frobware> sinzui: but wasn't this previously failing in CI, then confirmed as working once the images had been updated.
[17:48] <perrito666> bbl
[18:06]  * natefinch is a team of one, evidently.
[18:06] <redir> go team nate
[18:06] <redir> go team natefinch even
[18:06] <natefinch> :)
[18:07] <redir> rah rah ree kick em in the knee
[18:07] <mup> Bug #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] <natefinch> I 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 silly
[18:53] <redir> bbiab
[19:04] <natefinch> alexisb:
[19:34] <mup> Bug #1586150 opened: destroy-model does not remove the model <cdo-qa> <destroy-model> <juju-core:New> <https://launchpad.net/bugs/1586150>
[19:46] <mup> Bug #1586150 changed: destroy-model does not remove the model <cdo-qa> <destroy-model> <juju-core:New> <https://launchpad.net/bugs/1586150>
[19:55] <mup> Bug #1586150 opened: destroy-model does not remove the model <cdo-qa> <destroy-model> <juju-core:New> <https://launchpad.net/bugs/1586150>
[20:49] <mup> Bug #1586150 changed: destroy-model does not remove the model <cdo-qa> <destroy-model> <juju-core:New> <https://launchpad.net/bugs/1586150>
[20:56] <arosales> natefinch: katco: jsut as a heads up, if you have some time could you take a look at https://github.com/juju/docs/pull/1122
[20:57] <arosales> we need to get terms docs to users to so they can start prepping their charms for GA
[20:57] <arosales> 2.0 ga, that is
[20:57] <arosales> mbruzek: ^
[21:09] <rick_h_> arosales: ty, wil try to hook up cmars and his team with the docs folks as they did terms
[21:11] <cmars> rick_h_, arosales https://github.com/juju/docs/blob/master/src/en/developer-terms.md
[21:11] <rick_h_> cmars: <3
[21:13] <arosales> cmars: :-) so those land and I already referenced them on the list :-)
[21:14] <arosales> s/so/saw/
[21:15] <arosales> sorry earlier I meant to say resources we need a review on
[21:15] <arosales> per https://github.com/juju/docs/pull/1122
[21:15] <arosales> I think mbruzek was looking for a final ack from katco and natefinch
[21:15] <arosales> for resources on terms
[21:33] <cherylj> alexisb: release standup?
[21:56] <cherylj> tych0: ping?
[22:11] <mup> Bug #1585851 changed: Cannot restore-backup of controller model <backup-restore> <blocker> <ci> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1585851>
[22:14] <babbageclunk> hey menn0!
[22:15] <menn0> babbageclunk: hey hey!
[22:19] <babbageclunk> menn0: happy birthday for yesterday!
[22:19] <babbageclunk> menn0: Have you got a moment for a quick q?
[22:19] <menn0> babbageclunk: cheers
[22:19] <menn0> babbageclunk: sure
[22:20] <babbageclunk> menn0: I'm trying to get the full test suite passing with Mongo 3.2...
[22:21] <babbageclunk> menn0: But there are a couple of places where we get different errors now than we used to.
[22:21] <babbageclunk> menn0: *sometimes*
[22:21] <babbageclunk> menn0: So they make the tests flaky.
[22:22] <menn0> babbageclunk: that sounds fun :-/
[22:22] <babbageclunk> menn0: Well, it's a bit suboptimal.
[22:22] <menn0> babbageclunk: do you mean that for the same root cause mongodb returns different errors at times?
[22:22] <babbageclunk> menn0: Yeah - for example:
[22:23] <babbageclunk> https://github.com/babbageclunk/juju/commit/61da79e198d15263579f717da21e0e5925da0f3b
[22:24] <babbageclunk> menn0: Instead of a nice mgo.ErrCursor, we sometimes get a generic mgo.QueryError
[22:24] <menn0> babbageclunk: ah right... I even know about that one. https://bugs.launchpad.net/juju-core/+bug/1573286
[22:24] <mup> Bug #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:25] <babbageclunk> menn0: Ha!
[22:25] <babbageclunk> menn0: Ok, hadn't seen that.
[22:25] <menn0> babbageclunk: mwhudson created that ticket when he first ran into this
[22:25] <menn0> and told me about it
[22:25] <alexisb> wallyworld, menn0, cherylj, sinzui, rick_h_, I need some of your time i fyou are available
[22:26] <menn0> babbageclunk: I haven't put any thought into it yet
[22:26] <menn0> alexisb: i'm around
[22:26] <wallyworld> alexisb: ok
[22:26] <alexisb> https://plus.google.com/hangouts/_/canonical.com/juju-release
[22:26] <mwhudson> babbageclunk: wow, that general task is one hell of a welcome to the job
[22:26] <alexisb> mwhudson, yes yes it is
[22:27] <menn0> babbageclunk: let me have a think about that particular issue ... have to jump on this call
[22:27] <menn0> alexisb, mwhudson: luckily babbageclunk is a smart cookie :)
[22:27] <babbageclunk> menn0: 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] <babbageclunk> menn0: Ok, talk later.
[22:27] <mwhudson> menn0, alexisb: that's ok then :-)
[22:27]  * babbageclunk blushes.
[22:29] <babbageclunk> mwhudson: It seemed ok at first!
[22:30] <mwhudson> babbageclunk: that's a good sign, i guess :)
[22:31] <babbageclunk> mwhudson: I feel like it's *just this last bit*, but I've thought that for about 4 days now. :)
[22:31] <mwhudson> babbageclunk: heh
[22:32] <mwhudson> babbageclunk: did you beat the state tests into submission?
[22:32] <mwhudson> that seemed like the worst bit
[22:32] <babbageclunk> mwhudson: Yeah, that 100x slowdown is crazy!
[22:33] <babbageclunk> mwhudson: I mean, I've hacked around it, mostly (although they still run slower than with 2.4).
[22:34] <mwhudson> babbageclunk: oh yes, i saw something about that, emptying the db rather than recreating it?
[22:34] <babbageclunk> mwhudson: yuo
[22:34] <babbageclunk> uh, yup
[22:34] <mwhudson> babbageclunk: i also saw something running out of file descriptors sometimes, you've not hit that?
[22:34] <babbageclunk> mwhudson: No...
[22:35] <mwhudson> well good, i guess :)
[22:35] <babbageclunk> mwhudson: I saw your mention of it, but it's not happened to me.
[22:35] <babbageclunk> mwhudson: good unless it starts happening in builds I guess.
[22:35] <mwhudson> heh yes
[22:37] <babbageclunk> mwhudson: Right, I have to go sleep. Nice to meet you!
[22:37] <mwhudson> babbageclunk: good night!
[22:44] <mup> Bug #1585851 opened: Cannot restore-backup of controller model <backup-restore> <blocker> <ci> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1585851>
[22:46] <davechen1y> ci builds are failing because gopkg.in is unwell
[22:48] <anastasiamac_> davechen1y: see #juju
[22:49] <anastasiamac_> davechen1y: sinzui is onto it \o/ but landing is paused for now...
[22:55] <menn0> babbageclunk: i'm off the call now... what was your fix for the oplog test problem?
[22:56] <babbageclunk> menn0: I just in some code to check for the specific QueryError I was seeing, which is hacky but ok (I think).
[22:57] <babbageclunk> menn0: It's really the other one that's giving me pause - sending you an email 'cause I really need to go to bed.
[22:58] <babbageclunk> menn0: It turns out toddlers don't stay in bed later just because you got another baby!
[22:58] <menn0> babbageclunk: ok no problems. sleep is good :) i'll take a look at this today
[22:58] <babbageclunk> menn0: Who knew?
[23:01] <menn0> babbageclunk: yep :) Sander gets up and into our bed about 5:30am every day. Amelia sleeps in most days at least
[23:02] <babbageclunk> menn0: Say hi to the family! Night.
[23:02] <menn0> babbageclunk: goodnight!
[23:23] <mup> Bug #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>