[00:36] <davechen1y> http://reports.vapour.ws/releases/3495/job/run-unit-tests-wily-amd64/attempt/1131
[00:36] <davechen1y> the coder referenced here doesn't exist anynmore
[00:36] <davechen1y> did this bug get fixed ?
[00:37] <anastasiamac> davechen1y: the coder or the code?
[00:37] <mwhudson> that's a pretty severe penalty for introducing a race
[00:37] <davechen1y> the latter
[00:38] <mwhudson> davechen1y: it's on a branch?
[00:38] <mwhudson> the test fails for me
[00:38] <mwhudson> using go tip
[00:39] <davechen1y> mwhudson: which rev are you at ?
[00:39] <mwhudson> davechen1y: b9faceded0a321ffb39ba267f0a58a8a1c327fcb
[00:39] <davechen1y> mwhudson: can you try tip, 756f3303f3f7ab32ddb1509c33209c34e3e3bb01
[00:42] <mwhudson> davechen1y: yeah, github.com/juju/juju/worker/undertaker passes on master
[00:42] <davechen1y> i think this has been fixed by a refactoring that wagini landed recentlyh
[00:42] <davechen1y> there is no Kill method on this type any more
[03:28] <natefinch-afk> cherylj: updated that bug and the related one - it's been fixed for a while now
[03:28] <natefinch-afk> cherylj: sorry for forgetting to update the bug
[03:34] <cherylj> natefinch: upi
[03:34] <cherylj> whoops
[03:34] <cherylj> you'd better be sorry
[03:34] <cherylj> just kidding :)
[03:34] <cherylj> I had an off by one error
[03:43] <mup> Bug #1531718 changed: syslog full of "rsyslogd-2089: netstream session ... will be closed due to error" <juju-core:New> <https://launchpad.net/bugs/1531718>
[04:05] <natefinch> cherylj: ha
[04:05] <cherylj> :)
[10:02] <dooferlad> frobware, voidspace: hangout?
[10:02] <voidspace> dooferlad: frobware: grabbing coffee
[10:02] <voidspace> with you in 2
[10:15] <frobware> dooferlad, voidspace: http://reviews.vapour.ws/r/3497/
[10:16] <frobware> dooferlad, voidspace: http://reviews.vapour.ws/r/3498/
[10:31] <voidspace> frobware: LGTM on the short one
[10:34] <frobware> dooferlad, voidspace: https://github.com/frobware/juju/commit/d155428f662378ef4856dddcab7990fe16c347a8
[11:34] <frobware> dooferlad, voidspace: just a heads-up: we cannot land RB 3497 and 3498 without dooferlad's default gateway fix.
[11:35] <voidspace> frobware: ah, ok
[12:08] <frobware> dimitern, dooferlad, voidspace: some potential changes to ifup/down which we rely on https://bugs.launchpad.net/bugs/1337873
[12:08] <mup> Bug #1337873: ifupdown initialization problems caused by race condition <patch> <sts> <verification-failed> <ifenslave (Ubuntu):Fix Released> <ifupdown (Ubuntu):Fix Released by dgadomski> <ifenslave (Ubuntu Precise):Won't Fix> <ifupdown (Ubuntu Precise):Won't Fix> <ifenslave (Ubuntu Trusty):Fix
[12:08] <mup> Committed> <ifupdown (Ubuntu Trusty):In Progress> <ifenslave (Ubuntu Vivid):Fix Released> <ifupdown (Ubuntu Vivid):Won't Fix> <ifenslave (Ubuntu Wily):Fix Released> <ifupdown (Ubuntu Wily):In Progress> <ifupdown (Debian):New> <https://launchpad.net/bugs/1337873>
[13:15] <voidspace> frobware: heh
[13:15] <voidspace> frobware: long discussion
[13:15] <frobware> voidspace, yeah
[13:16] <frobware> very
[13:39] <cherylj> bless on 1.25!!  woohoo!!
[14:27] <ericsnow> katco, natefinch: upload is working now!  my patch is updated
[14:27] <ericsnow> natefinch: looks like show-service-resources post-deploy (but before upload) may not be right
[14:28] <ericsnow> natefinch: both resources are listed as "upload", but one of them should be "store" (unless I've misunderstood)
[14:29] <ericsnow> katco, natefinch: oh, and hurray for (literally) dreaming up solutions to problems! :)
[15:28] <natefinch> ericsnow, katco: well, upload seems to work, but I get a weird "invalid character 's' looking for beginning of value
[15:28] <natefinch> "
[15:29] <natefinch> ericsnow, katco: (error after running juju upload).  But juju show-service-resources says the upload succeeded (or at least enough to update the metadata)
[15:29] <ericsnow> natefinch: that's due to the "application/json" content type of the response (+ returning the bare string "success")
[15:29] <natefinch> lol
[15:30] <ericsnow> natefinch: yep, the error comes from building the response *after* upload is completed
[15:30] <natefinch> ericsnow: let's hack it so we don't see that error in the demo
[15:30] <natefinch> or something
[15:30] <ericsnow> natefinch: yep
[15:32] <katco> ericsnow: natefinch: lol just return "{}"
[15:53] <natefinch> ericsnow, katco: fixed the error.
[15:53] <ericsnow> natefinch: thanks
[15:55] <katco> natefinch: nice
[15:56] <natefinch> well it works, except I realized I screwed up the time display in show-service-resources, so it shows 2016-12-01 for today... which is quite confusing
[15:57] <natefinch> but a trivial fix
[15:59] <cherylj> can I get an easy review?  http://reviews.vapour.ws/r/3502/
[16:01] <natefinch> cherylj: ship it
[16:01] <cherylj> thanks natefinch!
[16:04] <natefinch> ericsnow, katco: http://pastebin.ubuntu.com/14478633/
[16:05] <ericsnow> natefinch: nice
[16:08] <katco> natefinch: very nice!
[16:12] <mup> Bug #1533262 opened: Add xenial to supported series <juju-core:Triaged by cherylj> <juju-core 1.25:Triaged by cherylj> <https://launchpad.net/bugs/1533262>
[16:35] <mattyw> fwereade, ping?
[16:36] <voidspace> fscking subnets cache
[16:49] <mup> Bug #1533275 opened: agent install dies randomly on Azure <juju-core:New> <https://launchpad.net/bugs/1533275>
[17:11] <natefinch> katco, ericsnow: anything I can do to help?
[17:12] <katco> natefinch: we haven't paired up yet; i'm wrapping up admin stuff. maybe after lunch we can pair
[17:13] <ericsnow> natefinch: review? https://github.com/juju/charm/pull/189
[17:14] <natefinch> ericsnow: I'm on it
[17:17] <ericsnow> natefinch: thanks
[17:19] <perrito666> aghhh I just went through the pain of rebasing master into my feature branch to now get github complaining that it cannot merge
[17:23] <natefinch> ericsnow: LGTM'd with a couple suggestions
[17:23] <ericsnow> natefinch: k, thanks
[20:01] <mup> Bug #1533338 opened: TestSupportedSeries broken by the addition of xenial <ci> <regression> <test-failure> <windows> <juju-core:New> <juju-core 1.25:Triaged by cherylj> <https://launchpad.net/bugs/1533338>
[20:04] <mup> Bug #1533338 changed: TestSupportedSeries broken by the addition of xenial <ci> <regression> <test-failure> <windows> <juju-core:New> <juju-core 1.25:Triaged by cherylj> <https://launchpad.net/bugs/1533338>
[20:07] <mup> Bug #1533338 opened: TestSupportedSeries broken by the addition of xenial <ci> <regression> <test-failure> <windows> <juju-core:New> <juju-core 1.25:Triaged by cherylj> <https://launchpad.net/bugs/1533338>
[20:22] <mup> Bug #1533338 changed: TestSupportedSeries broken by the addition of xenial <ci> <regression> <test-failure> <windows> <juju-core:New> <juju-core 1.25:Triaged by cherylj> <https://launchpad.net/bugs/1533338>
[20:22] <cherylj> can I get a review?  http://reviews.vapour.ws/r/3504/
[20:25] <mup> Bug #1533338 opened: TestSupportedSeries broken by the addition of xenial <ci> <regression> <test-failure> <windows> <juju-core:Invalid> <juju-core 1.25:Triaged by cherylj> <https://launchpad.net/bugs/1533338>
[20:28] <mup> Bug #1533338 changed: TestSupportedSeries broken by the addition of xenial <ci> <regression> <test-failure> <windows> <juju-core:Invalid> <juju-core 1.25:Triaged by cherylj> <https://launchpad.net/bugs/1533338>
[20:33] <natefinch> cd
[20:33] <natefinch> gah
[20:35] <natefinch> cherylj: lol
[20:35] <natefinch> cherylj: ship it
[20:35] <cherylj> heh, thanks natefinch :)
[20:36] <natefinch> cherylj: this is where I'd use jc.SameContents
[20:37] <cherylj> ah, yeah, I had forgotten about that
[20:37] <natefinch> cherylj: sorting works, though :)
[20:37] <natefinch> cherylj: actually, same contents is probably better
[20:37] <natefinch> cherylj: since I don't think we really need to require that the list is alphabetical
[20:37] <cherylj> ha, good thing I fatfingered the $$merge$$
[20:37] <natefinch> lol
[20:38] <cherylj> I'll go change it
[20:39] <natefinch> cherylj: I only remember it because I wrote it ;)
[20:40] <natefinch> cherylj: do you know if we still have a ton of failing tests on wily?  Because... I have a ton of failing tests, and I'm on wily
[20:40] <cherylj> natefinch: there still are failures, yes
[20:40] <natefinch> cherylj: gah
[20:41] <natefinch> cherylj: well that's a shame
[20:42] <cherylj> yeah, no kidding :/
[20:42] <natefinch> given that it's like 3 months since it was released :/
[20:43] <cherylj> natefinch: I updated http://reviews.vapour.ws/r/3504/
[20:44] <waigani> fwereade: ping
[20:45] <natefinch> cherylj: not to be a pain in the butt, but I think I'd keep the OSes separate.  It'll make it easier to maintain the list, I think (i.e. put xenial back after wily and put a blank line after it, and maybe a blank line before precise)
[20:46] <cherylj> natefinch: heh, ok.  Can you make that comment in the RB?
[20:46] <natefinch> done
[20:47] <natefinch> worst ship it ever? :)
[20:47] <cherylj> natefinch: it's like a string bet
[20:47] <cherylj> a string ship it?
[20:54] <cherylj> natefinch: 3rd time's a charm?
[20:56] <natefinch> cherylj: ship it, quick before I change my mind!
[20:56] <cherylj> merge like the wind!
[20:59] <natefinch> cherylj: btw, looks like master is in a much better state than our resources branch...  I guess we haven't merged in a while.
[20:59] <natefinch> cherylj: (wrt wily tests)
[20:59] <cherylj> natefinch: yeah that will help.  There were some recent changes to help, I think
[21:33] <natefinch> katco, ericsnow: I gotta run a little early today, but I can be on for a pretty long time later.  Send an update if there's stuff I can help with, otherwise, I'll see if I can get master merged into our branch (for after the demo)
[21:34] <ericsnow> natefinch: k
[21:36] <katco> natefinch-afk: k thx
[22:03] <cherylj> jog_: sinzui how old are the trusty images on the 1.8 maas?
[22:04] <jog_> cherylj, hmm not sure but I'll see if I can tell
[22:04] <sinzui> cherylj: I don't recall. I think they re from 8 months ago. jog: do you recall the age of the trusry images
[22:05] <jog_> cherylj, you mean the host that MAAS is running on or the images that are installed on deploy?
[22:05] <cherylj> jog_: the images installed on deploy
[22:05] <cherylj> if they're old and things need to be updated once they boot, it could cause this long test time
[22:06] <cherylj> and potentially conflicting updates from charms (contention for dpkg lock)
[22:07] <jog_> we have enable-os-upgrade: false set
[22:07] <cherylj> ah
[22:08] <cherylj> jog_: and enable-os-refresh-update?
[22:08] <jog_> that's not set
[22:08] <cherylj> it defaults to true
[22:09] <jog_> the maas syncs with http://maas.ubuntu.com/images/ephemeral-v2/releases/ every 60 minutes
[22:11] <cherylj> jog_: is there a way to get newer images?
[22:12] <jog_> cherylj, I'm not sure what's actually pulled from that location but the newest images there are July 30
 You are using Maas, do you know how old the images are?
 I remember getting these kind of errors when we used OLD images with the lxc provider
[22:14] <mbruzek> Hello cherylj and jog_
[22:15] <cherylj> welcome to the party mbruzek ;)
[22:15] <jog_> cherylj, I suppose we "could" point at daily but we want to test what we think is used in customer environments...
[22:15] <jog_> MAAS installs with the URL I gave above
[22:16] <jog_> hi mbruzek
[22:19] <mbruzek> What is the status of the latest deploy?
[22:19] <jog_> 26 minutes in... usually fails around 50 minutes
[22:20] <cherylj> jog_: would it be possible for me to ssh into the machines and inspect while it's running?
[22:20] <mbruzek> from the log that cherylj shared with me the first error was rabbitmq not starting
[22:20] <mbruzek> 2016-01-12 17:31:30 INFO config-changed  * Starting message broker rabbitmq-server
[22:20] <mbruzek> 2016-01-12 17:31:41 INFO config-changed  * FAILED - check /var/log/rabbitmq/startup_\{log, _err\}
[22:21] <jog_> cherylj, yes... I was just going to check if the rabbit machine was up
[22:24] <mbruzek> jog_: cherylj: is this not the charm store version of rabbitmq-server?
[22:24] <mbruzek> 2016-01-12 17:31:30 INFO config-changed  * Starting message broker rabbitmq-server 2016-01-12 17:31:41 INFO config-changed  * FAILED - check /var/log/rabbitmq/startup_\{log, _err\}
[22:24] <mbruzek> oops, i meant to paste this: 2016-01-12 17:26:16 INFO juju.worker.uniter.charm bundles.go:60 downloading local:trusty/rabbitmq-server-150 from https://10.0.80.105:17070/environment/4a6edd01-4253-4351-8ec8-e58cfe011a5e/charms?file=%2A&url=local%3Atrusty%2Frabbitmq-server-150
[22:25] <mbruzek> local:trusty/rabbitmq-server-150 seems like a different charm than the charm store version.  Maybe I am looking at the wrong code
[22:25] <jog_> rabbitmq-server-150 is what we're installing... it's the same bundle that the Openstack team uses
[22:26] <mbruzek> jog_: Then why isn't it the one that is in the charm store?  Can this maas server not get there?  Or is there special sauce?
[22:27] <mbruzek> jog_: I suspect they are not the same.  If you ran: "charm get trusty/rabbitmq-server" and diffed the directories that would tell the tale.  The rabbitmq-server charm is frequently updated.
[22:28] <jog_> beisner, do you know the history of why the 7-machine bundle is locked to rabbitmq-server-150?
[22:29] <jog_> cherylj, I know you know this but this is the same bundle that quickly passes with 1.25.2...
[22:30] <mbruzek> last update to rabbitmq-server was 2015-10-30 but a change from beisner went in at 2015-10-22
[22:30] <jog_> so just a bit confused as to how the bundled charm version would be the issue.
[22:33] <mbruzek> jog_: I am confused as to why you have a local copy of a charm.  Why not just lock a revision of the charm store charm with the bundle?
[22:34] <jog_> mbruzek, the Openstack team as a recommended bundle recipe that they test and release with. Juju-qa uses the same bundle to we stay in lock step with them.
[22:35] <mbruzek> jog_: OK but isn't there a charm store revision of the charm that works?  Why the need for a local charm.  Are all the charms local?
[22:36] <mbruzek> jog_: I am just trying to help diagnose this failure, and perhaps I am not being successful at understanding the context.
[22:36] <jog_> ah... I think juju deployer downloads the charm initially and then installed them
[22:37] <jog_> yup... looking at deployer logs... it branches all the charm code first
[22:38] <mbruzek> OK
[22:41] <ericsnow> katco: could you take a look at http://reviews.vapour.ws/r/3506/?
[22:41] <ericsnow> katco: mostly, it is a port of the fingerprint stuff from the charm repo to the utils repo
[22:43] <katco> ericsnow: sure
[22:51] <katco> ericsnow: sorry was in a meeting... what are the new bits in this?
[22:53] <ericsnow> katco: just lining up fingerprints with other hash-related tools in utils
[22:53] <ericsnow> katco: Fingerprint is also decoupled from a particular hash type
[22:53] <katco> ericsnow: ah cool
[23:05] <katco> ericsnow: some nice code
[23:11] <mup> Bug #1527020 changed: cannot build trusty ppc64el juju without forcing GOARCH <ppc64el> <regression-update> <trusty> <juju-core:Fix Released> <gccgo-go (Ubuntu):Invalid> <https://launchpad.net/bugs/1527020>
[23:14] <mup> Bug #1527020 opened: cannot build trusty ppc64el juju without forcing GOARCH <ppc64el> <regression-update> <trusty> <juju-core:Fix Released> <gccgo-go (Ubuntu):Invalid> <https://launchpad.net/bugs/1527020>
[23:17] <mup> Bug #1527020 changed: cannot build trusty ppc64el juju without forcing GOARCH <ppc64el> <regression-update> <trusty> <juju-core:Fix Released> <gccgo-go (Ubuntu):Invalid> <https://launchpad.net/bugs/1527020>
[23:20] <mup> Bug #1527020 opened: cannot build trusty ppc64el juju without forcing GOARCH <ppc64el> <regression-update> <trusty> <juju-core:Fix Released> <gccgo-go (Ubuntu):Invalid> <https://launchpad.net/bugs/1527020>
[23:23] <mup> Bug #1527020 changed: cannot build trusty ppc64el juju without forcing GOARCH <ppc64el> <regression-update> <trusty> <juju-core:Fix Released> <gccgo-go (Ubuntu):Invalid> <https://launchpad.net/bugs/1527020>
[23:41] <mattyw> anastasiamac, hey hey
[23:42] <anastasiamac> mattyw: \o/
[23:50] <ericsnow> katco: have time for an ultra-quick review? http://reviews.vapour.ws/r/3509/