[00:14] <waigani> axw_: #1441478 when you say it "bails if any of the instances cannot be found", are you talking about the txn.DocExists assert in the upgrade step?
[00:14] <mup> Bug #1441478: state: availability zone upgrade fails if containers are present <upgrade-juju> <juju-core:Triaged> <juju-core 1.24:In Progress by waigani> <https://launchpad.net/bugs/1441478>
[00:14] <wallyworld> thumper: can you recall what happens in jujud panics in it's Run() method - will the upstart service restart the agent?
[00:15] <wallyworld> ah yes i think it does
[00:19] <thumper> wallyworld: can we chat earlier today?
[00:19] <thumper> wallyworld: and yes, upstart restarts
[00:19] <wallyworld> sure, free whenever
[00:19] <thumper> kk, just making some toast, with you shortly
[00:25] <thumper> wallyworld: in our hangout now
[01:15] <axw_> waigani: was taking my daughter to school, looking now
[01:19] <axw_> waigani: I mean the azFunc function may return environs.ErrNoInstances
[01:19] <waigani> axw_: ah right, okay thanks
[01:21] <waigani> I've setup maas with a few nodes on my laptop to test, got juju bootstrapped, but after a destroy env and rebootstrap I've run afoul of #1412621
[01:21] <mup> Bug #1412621: replica set EMPTYCONFIG MAAS bootstrap <bootstrap> <maas-provider> <mongodb> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1412621>
[01:22] <waigani> so looking at the original bug, but ironing out maas issues along the way
[02:02] <mup> Bug #1459885 was opened: harvest mode setting not used by container provisioner <juju-core:Triaged> <https://launchpad.net/bugs/1459885>
[02:02] <axw_> wallyworld: 1:1?
[02:02] <wallyworld> oh yeah
[02:12] <davecheney> https://github.com/juju/juju/pull/2447
[02:12] <davecheney> can I get a review on this
[02:12] <davecheney> it shits me to tears every time I got to fix a bug in one of our libraries
[02:13] <davecheney> i find that juju is lagging behind using fixes that have landed in it by months
[02:16] <davecheney> thumper: waigani http://reviews.vapour.ws/r/1810/
[02:16] <davecheney> all the on call reviewers are in the EU timezoen today
[02:16] <davecheney> do you have a second to take a look
[02:17] <waigani> davecheney: it's just an dependencies update?
[02:17] <waigani> s/an/a
[02:17] <davecheney> yup
[02:17] <waigani> LGTM
[02:17] <davecheney> danka
[02:28] <natefinch> if only there were some way to automatically pull from the head revision, so we'd always get all the new fixes....
[02:29] <davecheney> nah, that leads to madness
[02:29] <davecheney> and irreproducible builds
[02:29] <davecheney> what i don't understand is
[02:29] <natefinch> you can freeze release branches
[02:29] <davecheney> when I land a fix on juju/tesing
[02:29] <davecheney> it's because I need it to fix a bug in juju
[02:29] <natefinch> ]I don't understand why we freeze a development branch, though
[02:29] <davecheney> who is landing fixes on juju/testing that doesn't need them ?
[02:30] <natefinch> davecheney: probably people working on the charm store etc
[02:30] <natefinch> also, shouldn't it be obvious in the commit log? L)
[02:30] <natefinch> :)
[02:33] <wallyworld> natefinch: it's generally accepted pulling tip of your dependencies is bad - but Go does a lot of things I disagree with :-)
[02:37] <natefinch> wallyworld: I guess the problem is that we don't have CI running across all tests that use our own dependencies, so in theory, changing github.com/juju/testing could break charm store if we only test the change in juju-core
[02:38] <natefinch> wallyworld: otherwise, really, it's not a dependency.... it's just our code.  Anymore than github.com/juju/juju/agent is a "dependency" of github.com/juju/juju/state ...
[02:38] <wallyworld> natefinch: yeah, the Go approach works ok if you consider all the source code in the entire repo part of your project, which is what googles does
[02:38] <wallyworld> but for shared libraries not so well
[02:39] <natefinch> wallyworld: we probably should, since otherwise we can get into a state where the charm store makes a change to testing for its needs, and then when juju-core updates, that change is incompatible with our own code
[02:40] <wallyworld> the overriding facror though needs to be reproducable builds
[02:40] <natefinch> ....for release branches
[02:40] <wallyworld> and proper dependency management
[02:40] <natefinch> not master
[02:40] <natefinch> nobody is reproducing builds off master
[02:40] <wallyworld> hmmm
[02:41] <wallyworld> let's add this to the "discuss over several red wines" list
[02:41] <natefinch> haha
[02:41] <wallyworld> the more the better :-)
[02:41] <natefinch> someday, someone will actually be able to explain to me what "proper dependency management" means.   Because everyone seems to have different - usually fairly fuzzy and not actionable - ideas about it.
[02:44] <wallyworld> repeatable builds, explicitly choosing the version/revno of the lib you want to link to/ build against, and a way to manage and track that
[02:45] <natefinch> so, like godeps
[02:52] <davecheney> natefinch: well, they are going to have very bad day when I land my refactor
[02:54] <natefinch> davecheney: what are you refactoring?
[02:54] <davecheney> https://launchpad.net/bugs/1459064
[02:54] <mup> Bug #1459064: worker/leadership: data races in test and code <intermittent-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1459064>
[02:55] <natefinch> ahh awesome
[02:55] <natefinch> davecheney: not sure who they is, and why that would make them have a bad day
[02:57] <davecheney> imma in your package, breakin your api
[02:58] <natefinch> see, you're not supposed to do that :)
[02:59] <davecheney> what if your api is not thread safe
[02:59] <natefinch> time for v2
[02:59] <davecheney> and the package is supposed to be used in a multithreaded manner ?
[03:00] <natefinch> heh ouch
[03:00] <natefinch> then you screwed up.  I guess in that case, you break the API and then because everyone's pulling tip, they are helpfully given compile errors that tell them they need to update their code because the old code is totally borked.
[03:01] <natefinch> as opposed to when you're pinning revisions and you go on forever using that old racy P.O.S. code
[03:01] <davecheney> sounds like youre scrrewed either way
[03:01] <davecheney> have fun
[03:01] <natefinch> Yes. but I'd rather know than go on thinking I'm ok
[03:32] <mup> Bug #1459288 changed: TestWriteTokenReplaceExisting fails <blocker> <ci> <regression> <unit-tests> <windows> <juju-core:Fix Released by wallyworld> <juju-core 1.24:Fix Released by wallyworld> <https://launchpad.net/bugs/1459288>
[03:32] <mup> Bug #1459616 changed: 'juju status' timestamps should use rfc3339 or ISO8601 <juju-core:Won't Fix> <https://launchpad.net/bugs/1459616>
[04:08] <mup> Bug #1459912 was opened: juju agent opens api when upgrade is pending <juju-core:In Progress by wallyworld> <juju-core 1.24:Fix Committed by wallyworld> <https://launchpad.net/bugs/1459912>
[04:12] <davecheney> http://reviews.vapour.ws/r/1813/
[05:12] <wallyworld> axw_: can i please get a trivial review? http://reviews.vapour.ws/r/1817/
[05:12] <axw_> looking
[05:16] <waigani> axw_, wallyworld: Here is the PR for #1441478 http://reviews.vapour.ws/r/1818/ I've hit EOD trying to manually test this on maas (hit other maas bugs). So I can follow up with manual testing
[05:16] <mup> Bug #1441478: state: availability zone upgrade fails if containers are present <upgrade-juju> <juju-core:Triaged> <juju-core 1.24:In Progress by waigani> <https://launchpad.net/bugs/1441478>
[05:16] <wallyworld> waigani: ty
[05:17] <wallyworld> waigani: are these maas bugs known? do you need to report them?
[05:17] <waigani> wallyworld: actually yes they are
[05:18] <wallyworld> oh joy, makes it hard for us
[05:18] <wallyworld> axw_: ty for review, i need to head to doctor to get more cholesterol medicine, will review your tags one when i get back
[05:18] <axw_> thanks
[05:19] <waigani> wallyworld: thumper has given me some other maas bugs to look at while I'm in maas land - so I'll have a maas(ive) bug list to keep going on next week :)
[05:19] <wallyworld> waigani: yeah, i told him to give you that one :-P
[05:19] <waigani> thanks :/
[05:19] <wallyworld> anytime :-)
[05:19] <wallyworld> figured you were on a roll
[05:19] <waigani> heh
[05:19] <wallyworld> the right man for the job
[05:20] <waigani> more like a tumble ....
[05:21] <waigani> but good to get the MAAS knowledge
[05:22] <axw_> waigani: LGTM, thanks
[05:23] <waigani> axw_: wow, quick thanks :)
[05:49] <axw_> wallyworld: please see my reply on the lease change, when you're back
[07:15] <wallyworld> axw_: thanks for reply, ship it i reckon
[09:00] <voidspace> Fledgling MAAS cluster: PDU, switch, plus two proliant servers
[09:00] <voidspace> https://www.dropbox.com/s/fvmz7aj5lsvk0pb/2015-05-29%2009.55.44%20HDR.jpg?dl=0
[09:00] <voidspace> dooferlad: ^^
[09:06] <voidspace> dimitern: https://www.dropbox.com/s/fvmz7aj5lsvk0pb/2015-05-29%2009.55.44%20HDR.jpg?dl=0
[09:24] <perrito666> good morning
[09:25] <mwhudson> voidspace: do the proliants have bmcs, or is that what the pdu is for?
[09:33] <dooferlad> mwhudson: the proliants have an API that you can poke over one of their network interfaces, but voidspace judged that engineer time to get that doing what we wanted vs cost of a PDU favoured shopping over typing
[09:34] <dooferlad> mwhudson: it would be interesting to play with one at some point - apart from being larger than a NUC, if we can get the RESTful API doing what we need, they will be great for a home MAAS
[09:34] <mwhudson> ah not ilo or ipmi or anything like that?
[09:36] <dooferlad> mwhudson: I belive it is iLO
[09:38] <mwhudson> huh apparently maas only supports the kind of ilo you get in moonshots?
[09:39] <voidspace> I'm sure it's possible to get it working
[09:39] <voidspace> a
[09:39] <voidspace> a PDU seemed the path of least resistance though
[09:39] <voidspace> and means I can plug other things in - like my older N36 proliant
[11:22] <waigani> wallyworld: ping
[11:30] <wallyworld> waigani: HI
[11:30] <waigani> wallyworld: hey, just saw your email - pushing up a targeted PR to 1.24
[11:31] <wallyworld> waigani: you rock, thank you
[11:32] <waigani> wallyworld: the bug was in a 1.22 upgrade step - hence the 1.22 target. I intended to forward port up each version. Should I also target 1.23?
[11:37] <waigani> wallyworld: landing on 1.24: https://github.com/juju/juju/pull/2456
[11:50] <wallyworld> waigani: sorry, was afk, bit of an emergency here. but if you've proposed for 1.22, mat was well do 1.23 as well
[11:50] <wallyworld> thanks for 1.24, that's great
[13:52] <mup> Bug #1460071 was opened: relation-set --file ignores --format <juju-core:New> <https://launchpad.net/bugs/1460071>
[14:24] <voidspace> dooferlad: ping
[14:24] <dooferlad> voidspace: pong
[14:25] <voidspace> dooferlad: I'd like to setup a network for my maas - and I'd like you to help if you can :-)
[14:25] <dooferlad> sure, give me 5 minutes to finish this review
[14:25] <voidspace> I have a switch plus cables and spare ethernet port on my desktop
[14:25] <voidspace> sure
[14:25] <voidspace> and maas running on my desktop
[14:31] <mup> Bug #1460087 was opened: quickstart deployment fails to add relations when bootstrap goes "down" <juju-core:New> <https://launchpad.net/bugs/1460087>
[14:36] <dooferlad> voidspace: right, what do you want to know? Should we jump in a hangout?
[14:37] <voidspace> dooferlad: hangout is good
[14:37] <voidspace> dooferlad: sapphire?
[14:38] <dooferlad> voidspace: yep
[14:38] <voidspace> I'm there
[14:39] <dooferlad> voidspace:  so am I... did you hit join? That is my usual problem.
[14:39] <voidspace> dooferlad: juju-sapphire?
[14:39] <voidspace> dooferlad: I'm in
[14:40] <voidspace> "waiting for people to join this video call..."
[14:40] <voidspace> I'll leave and re-join
[15:56] <natefinch> It's a good thing we use *_test packages to only test the exported interface of an API: https://github.com/juju/juju/blob/master/upgrades/export_test.go
[15:56] <natefinch> s/API/package/
[16:19] <mup> Bug #1460071 changed: relation-set --file ignores --format <juju-core:Invalid> <https://launchpad.net/bugs/1460071>
[16:31] <voidspace> dimitern: struggling to join the conference
[16:31] <voidspace> dimitern: the number on the event for London is wrong
[16:40] <dimitern> voidspace, hey, I won't manage
[16:40] <dimitern> voidspace, but if you can, please do and we'll chat later
[16:41] <voidspace> dimitern: it's been cancelled - to be reconvened
[16:41] <voidspace> dimitern: was a terrible connection :-/
[16:57] <dimitern> voidspace, ok, thanks for the heads up
[17:35] <cherylj> ericsnow: ping?
[18:34] <mup> Bug #1460171 was opened: Deployer fails because juju thinks it is upgrading <blocker> <ci> <deployer> <regression> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1460171>
[18:40] <mup> Bug #1460175 was opened: apiserver_test authhttp_test SetUpTest.debugLogSuite failed <intermittent-failure> <ppc64el> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1460175>
[19:13] <natefinch> man I love unit tests. I don't know how I ever wrote code that worked without them.
[19:28] <dimitern> any reviewers around to have a look at http://reviews.vapour.ws/r/1821/ ? this (hopefully) fixes the critical bugs#1449054 and #1452221
[19:28] <dimitern> fwereade, fyi ^^
[19:28]  * dimitern @eod
[19:32] <ericsnow> cherylj: sorry, I totally missed your ping
[19:39] <perrito666> mm, chaining hooks seems to be something less trivial than expected
[19:40] <cherylj> ericsnow: np, I answered my own question :)
[19:40] <ericsnow> :)
[19:41] <mup> Bug #1460184 was opened: Bootstrapping fails with Maas on Ubuntu Vivid <maas-provider> <vivid> <juju-core:Incomplete> <https://launchpad.net/bugs/1460184>
[19:50] <perrito666> once again my isp did not show to install the upgrade, if I did not work at home I would already have lost 2 work days waiting for them
[20:38] <natefinch> people who write functions that take 5 strings should be flogged
[22:35] <mup> Bug #1459616 was opened: 'juju status' timestamps should use rfc3339 or ISO8601 <juju-core:New> <https://launchpad.net/bugs/1459616>
[22:41] <ericsnow> cherylj: thanks for revising that