davechen1y | ping alexisb | 00:37 |
---|---|---|
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:38 |
davechen1y | thanks | 00:39 |
alexisb | davechen1y, responded | 00:41 |
davechen1y | alexisb: ta | 00:41 |
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:45 |
anastasiamac_ | davechen1y: is it blocker? u can't just use $$fixes-blah$$? | 00:47 |
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:49 |
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:50 |
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:51 |
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:52 |
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:54 |
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:55 |
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:56 |
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:57 |
davechen1y | sinzui: i dont' have a login for that site | 00:58 |
davechen1y | or chrome has forgotten them :( | 00:58 |
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:10 |
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:22 |
=== Makyo is now known as Makyo|away | ||
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:28 |
wallyworld | axw: a small one when you are free http://reviews.vapour.ws/r/4905/ | 01:29 |
=== natefinch-afk is now known as natefinch | ||
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:31 |
wallyworld | axw: new dep i suspect | 01:32 |
wallyworld | httprequest maybe | 01:32 |
axw | wallyworld: that function just uses net/http AFAICS | 01:32 |
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:34 |
* redir goes eod | 01:35 | |
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:40 |
axw | wallyworld: I see you reverted, did you get to the bottom of it? | 02:37 |
wallyworld | axw: nope, master failed in the same way, nfi | 02:38 |
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:40 |
wallyworld | axw: you happy to +1 with that error message reverted? | 02:48 |
axw | wallyworld: yep, will do | 02:48 |
wallyworld | ta | 02:48 |
axw | wallyworld: done | 02:49 |
wallyworld | ty | 02:49 |
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:10 |
mup | Bug #1585856 opened: worker/txnpruner: test failure during ci <juju-core:New> <https://launchpad.net/bugs/1585856> | 03:31 |
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> | 03:52 |
wallyworld | axw: as per roger's suggestion, i added extra tests and improved the marshalling https://github.com/juju/charm/pull/210 | 04:00 |
axw | wallyworld: LGTM | 04:03 |
wallyworld | ty | 04:03 |
wallyworld | axw: small one, https://github.com/juju/idmclient/pull/17 | 04:20 |
wallyworld | there's sooooo many :-( | 04:21 |
=== redir is now known as redir_afk | ||
wallyworld | axw: idmclient just uses UserTag so v1 and v2 are the same in that respect | 04:56 |
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 | 04:57 |
=== urulama|swap is now known as urulama | ||
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> | 05: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> | 06:29 |
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:38 |
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:44 |
wallyworld | axw: google hates me, be there in a sec | 06:45 |
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:53 |
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> | 07:17 |
=== frankban|afk is now known as frankban | ||
=== frankban is now known as frankban|afk | ||
=== frankban|afk is now known as frankban | ||
babbageclunk | frobware: 1:1? | 08:31 |
frobware | babbageclunk: yep, sent link via PM | 08:32 |
frobware | dimitern, dooferlad: standup | 09:02 |
dooferlad | frobware: just booking some passport stuff. There soon. | 09:02 |
frobware | dooferlad: k | 09:02 |
=== akhavr1 is now known as akhavr | ||
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:19 |
voidspace | fwereade: ping | 10:23 |
fwereade | voidspace, pong | 11:44 |
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:06 |
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:07 |
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:08 |
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:14 |
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:15 |
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:16 |
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:17 |
fwereade | voidspace, core/description.Model has a Validate method | 12:19 |
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:20 |
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:21 |
voidspace | fwereade: cool, you answered my question anyway | 12:22 |
voidspace | fwereade: appreciated | 12:22 |
frobware | cherylj: ok to merge http://reviews.vapour.ws/r/4903/ ? | 13:03 |
frobware | dooferlad: ping | 13:28 |
dooferlad | frobware: pong | 13:30 |
frobware | dooferlad: having trouble with your bridge script changes - can we HO? | 13:30 |
dooferlad | frobware: sure | 13:32 |
dooferlad | frobware: juju-sapphire? | 13:32 |
frobware | yep | 13:32 |
babbageclunk | voidspace: ping? | 13:48 |
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 | 13:51 |
babbageclunk | dimitern: ping? | 14:08 |
dimitern | babbageclunk: pong | 14:08 |
babbageclunk | dimitern: I'm trying to debug a flaky test I'm hitting. | 14:09 |
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:10 |
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:11 |
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:12 |
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:13 |
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:14 |
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:15 |
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:16 |
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:17 |
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:18 |
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:20 |
lazyPower | ping natefinch | 14:21 |
babbageclunk | dimitern: Ok, I think I follow - I'll try changing export_test to make it work. | 14:21 |
dimitern | babbageclunk: that is important for patching functions, not so much for simple vars (e.g. exposing struct foo{unexp. fields..}) | 14:23 |
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:24 |
frobware | dimitern, jam: were we going to talk about fan/networking today? | 14:25 |
dimitern | frobware: we still can :) | 14:29 |
voidspace | babbageclunk: sorry, was on lunch | 14:44 |
babbageclunk | voidspace: No worries. Picked dimitern's brains instead, although I'm still a bit stuck | 14:45 |
voidspace | babbageclunk: yeah, read the backscroll | 14:46 |
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:47 |
babbageclunk | So maybe I should change subnets.go to assign PickAddress (and call it) and remove the alias from export_test? | 14:49 |
voidspace | babbageclunk: the alias is needed to allow patching | 14:50 |
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:51 |
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:52 |
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:53 |
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:54 |
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:56 |
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:58 |
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. | 14:59 |
voidspace | babbageclunk: why wasn't it? | 15:04 |
babbageclunk | voidspace: because I added it to mockPickAddress, which wasn't being called. | 15:05 |
voidspace | ah! | 15:06 |
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:10 |
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:11 |
* katco needs to reboot | 15:43 | |
alexisb | frobware, dimitern, just sent a note, take a look and let me know | 15:44 |
frobware | alexisb: looking | 15:45 |
dimitern | alexisb: sure | 15:46 |
dimitern | alexisb: replied | 15:55 |
alexisb | dimitern, thanks | 15:55 |
natefinch | fwereade: you around? | 16:16 |
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:18 |
=== frankban is now known as frankban|afk | ||
babbageclunk | perrito666: ping? | 16:47 |
perrito666 | babbageclunk: pong | 16:47 |
babbageclunk | perrito666: I'm just trying to finish up these mongo3.2 changes... | 16:48 |
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:49 |
babbageclunk | perrito666: one of them is in OplogTailer | 16:50 |
perrito666 | mh, I am not familiar with it | 16:51 |
babbageclunk | perrito666: Doh, I thought I saw your name on it, sorry! | 16:51 |
perrito666 | babbageclunk: I might have passed by changing something | 16:52 |
perrito666 | but I am pretty sure its one of menn0's | 16:52 |
babbageclunk | perrito666: yup, you're right | 16:53 |
perrito666 | sorry that was not helpful :( | 16:53 |
babbageclunk | perrito666: Well, I'll bug him about this instead! Sorry! | 16:54 |
babbageclunk | perrito666: :) | 16:54 |
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:01 |
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:02 |
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:03 |
frobware | babbageclunk, dooferlad, voidspace ^^ | 17:04 |
dimitern | frobware: let me do a quick test locally.. | 17:05 |
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:16 |
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:17 |
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:18 |
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:20 |
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:21 |
frobware | dimitern: sigh. that was a waste of a few hours. | 17:23 |
frobware | dimitern: sometimes it feels hard to make progress. :( | 17:23 |
frobware | dimitern: I'm surprisd this is not showing up in CI tests | 17:24 |
frobware | sinzui: ^^ | 17:24 |
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:26 |
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:27 |
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:28 |
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:30 |
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:31 |
dimitern | frobware: good plan :) | 17:34 |
dimitern | frobware:http://reviews.vapour.ws/r/4915/ | 17:35 |
frobware | dimitern: looking but will mostly try first. | 17:35 |
dimitern | frobware: +1 | 17:35 |
frobware | dimitern: for a repro, just deploy 20 units? | 17:36 |
dimitern | frobware: yeah - less than 20 should still work | 17:36 |
dimitern | frobware: ah! important: make sure your lxdbr0 is configured to give *both* ipv4 and ipv6 addresses | 17:37 |
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:38 |
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:39 |
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:40 |
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:41 |
frobware | sinzui: but I did go through a stage where a trusty MAAS node had backports enabled. | 17:42 |
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:45 |
frobware | sinzui: but wasn't this previously failing in CI, then confirmed as working once the images had been updated. | 17:46 |
perrito666 | bbl | 17:48 |
* natefinch is a team of one, evidently. | 18:06 | |
redir | go team nate | 18:06 |
redir | go team natefinch even | 18:06 |
natefinch | :) | 18:06 |
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:07 |
redir | bbiab | 18:53 |
natefinch | alexisb: | 19:04 |
mup | Bug #1586150 opened: destroy-model does not remove the model <cdo-qa> <destroy-model> <juju-core:New> <https://launchpad.net/bugs/1586150> | 19:34 |
mup | Bug #1586150 changed: destroy-model does not remove the model <cdo-qa> <destroy-model> <juju-core:New> <https://launchpad.net/bugs/1586150> | 19:46 |
mup | Bug #1586150 opened: destroy-model does not remove the model <cdo-qa> <destroy-model> <juju-core:New> <https://launchpad.net/bugs/1586150> | 19:55 |
mup | Bug #1586150 changed: destroy-model does not remove the model <cdo-qa> <destroy-model> <juju-core:New> <https://launchpad.net/bugs/1586150> | 20:49 |
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:56 |
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: ^ | 20:57 |
rick_h_ | arosales: ty, wil try to hook up cmars and his team with the docs folks as they did terms | 21:09 |
cmars | rick_h_, arosales https://github.com/juju/docs/blob/master/src/en/developer-terms.md | 21:11 |
rick_h_ | cmars: <3 | 21:11 |
arosales | cmars: :-) so those land and I already referenced them on the list :-) | 21:13 |
arosales | s/so/saw/ | 21:14 |
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:15 |
cherylj | alexisb: release standup? | 21:33 |
=== meetingology` is now known as meetingology | ||
cherylj | tych0: ping? | 21:56 |
mup | Bug #1585851 changed: Cannot restore-backup of controller model <backup-restore> <blocker> <ci> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1585851> | 22:11 |
babbageclunk | hey menn0! | 22:14 |
menn0 | babbageclunk: hey hey! | 22:15 |
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:19 |
babbageclunk | menn0: I'm trying to get the full test suite passing with Mongo 3.2... | 22:20 |
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:21 |
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:22 |
babbageclunk | https://github.com/babbageclunk/juju/commit/61da79e198d15263579f717da21e0e5925da0f3b | 22:23 |
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:24 |
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:25 |
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:26 |
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:27 | |
babbageclunk | mwhudson: It seemed ok at first! | 22:29 |
mwhudson | babbageclunk: that's a good sign, i guess :) | 22:30 |
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:31 |
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:32 |
babbageclunk | mwhudson: I mean, I've hacked around it, mostly (although they still run slower than with 2.4). | 22:33 |
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:34 |
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:35 |
babbageclunk | mwhudson: Right, I have to go sleep. Nice to meet you! | 22:37 |
mwhudson | babbageclunk: good night! | 22:37 |
mup | Bug #1585851 opened: Cannot restore-backup of controller model <backup-restore> <blocker> <ci> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1585851> | 22:44 |
davechen1y | ci builds are failing because gopkg.in is unwell | 22:46 |
anastasiamac_ | davechen1y: see #juju | 22:48 |
anastasiamac_ | davechen1y: sinzui is onto it \o/ but landing is paused for now... | 22:49 |
menn0 | babbageclunk: i'm off the call now... what was your fix for the oplog test problem? | 22:55 |
babbageclunk | menn0: I just in some code to check for the specific QueryError I was seeing, which is hacky but ok (I think). | 22:56 |
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:57 |
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? | 22:58 |
menn0 | babbageclunk: yep :) Sander gets up and into our bed about 5:30am every day. Amelia sleeps in most days at least | 23:01 |
babbageclunk | menn0: Say hi to the family! Night. | 23:02 |
menn0 | babbageclunk: goodnight! | 23:02 |
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> | 23:23 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!