[00:33] <davecheney> software http://paste.ubuntu.com/15248178/
[00:36] <perrito666> beautiful
[00:43] <thumper> davecheney: ping
[00:43] <thumper> davecheney: I have []someDocType, and a method Insert(docs ...interface{})
[00:44] <thumper> is there an easy way to squich the former into the latter?
[00:44] <thumper>  cannot use docs (type []historicalStatusDoc) as type []interface {} in argument to statusHistory.Writeable().Insert
[00:46] <thumper> menn0: ^^ any ideas?
[00:47] <thumper> nm
[00:47] <thumper> found an easy soluntion
[00:50] <menn0> thumper: sorry i'm on my way out to run an errand
[00:50] <thumper> don't worry
[00:50] <thumper> all sorted
[00:50] <sinzui> katco: cherylj as a formality, can you approve we want to merge feature-resources into master http://reviews.vapour.ws/r/4007/
[00:52] <thumper>     c.Check(importedHistory[i].Since, gc.Equals, exportedHistory[i].Since)
[00:52] <thumper> ... obtained *time.Time = &time.Time{sec:63592390248, nsec:901470923, loc:(*time.Location)(0x3fc4ec0)} ("2016-03-01 13:50:48.901470923 +1300 NZDT")
[00:52] <thumper> ... expected *time.Time = &time.Time{sec:63592390248, nsec:901470923, loc:(*time.Location)(0x3fc4ec0)} ("2016-03-01 13:50:48.901470923 +1300 NZDT")
[00:52] <thumper> who can spot the difference?
[00:53] <thumper> deepequals necessary?
[00:55] <thumper> yep
[00:55] <thumper> need jc.DeepEquals
[00:59] <cherylj> sinzui: shipit!
[00:59] <sinzui> thank you cherylj
[01:00] <sinzui> ouch cherylj I cannot merge, sorry katco, feature-resources now conflicts with master https://github.com/juju/juju/pull/4569
[01:01] <cherylj> :(
[01:33] <davecheney> thumper: http://reviews.vapour.ws/r/4009/
[01:34] <thumper> davecheney: shipit
[01:34] <davecheney> thumper: thanks
[01:36] <thumper> np
[02:54] <davecheney> thumper: http://reviews.vapour.ws/r/4013/
[02:55] <davecheney> another one for you
[03:31] <davecheney> thumper: http://reviews.vapour.ws/r/4014/
[04:12]  * thumper is out now
[04:12] <thumper> probably back later tonight, because, you know, busy...
[05:22] <davecheney> Hey thumper, look what we get noe
[05:22] <davecheney> 	local error: bad record MAC
[05:22] <davecheney> 	github.com/juju/juju/state/open.go:208: cannot create index
[05:22] <davecheney> 	github.com/juju/juju/state/open.go:239:
[05:22] <davecheney> 	github.com/juju/juju/state/open.go:83:
[05:22] <davecheney> 	github.com/juju/juju/state/open.go:114:
[09:26] <jam> mgz: bug 1549545 would be good to discuss when you're around
[09:26] <mup> Bug #1549545: Bundle deploys fail at lxc-start when bridge br-eth1 is created <ci> <deploy> <maas-provider> <test-failure> <juju-core:Triaged by dimitern> <https://launchpad.net/bugs/1549545>
[09:26] <mgz> jam, sure thing
[09:29] <mgz> jam: I thought from the previius chatter dimitern had a pretty good idea what was up
[09:30] <mgz> ...what is that... 'previius'? jesu
[09:30] <jam> I think it is the Previous Prius
[09:31] <jam> mgz: so, dimitern is working on making sure Juju 2.0 supports multiple nics, but since it doesn't yet, it seems that we shouldn't have the lab set up to require it.
[09:31] <mgz> ehehe
[09:31] <jam> I thought bug #1549545 was preventing us from getting a blessed release
[09:31] <mup> Bug #1549545: Bundle deploys fail at lxc-start when bridge br-eth1 is created <ci> <deploy> <maas-provider> <test-failure> <juju-core:Triaged by dimitern> <https://launchpad.net/bugs/1549545>
[09:31] <jam> and while it is a configuration we want to support, it wasn't supported in the past.
[09:32] <jam> OR did we actually break a mode that was working previously?
[09:32] <mgz> so, the reason we do is that it was a bug in 1.x to pick the wrong nic and fail, and the extra interfaces (and ordering of them) was to catch regressions to the handlign there
[09:32] <jam> so we did regress vs 1.x behavior
[09:33] <mgz> we can release with the bug and put it in release notes, so it's not blocking as such
[09:33] <jam> where we only supported 1, but we detected which was the default gateway
[09:33] <mgz> jam: yeah, see the history of the maas-1_9-deployer job say, 1.25 passes
[09:34] <jam> mgz: so in CI, is any particular job always run on the same hardware in the same configuration? and it is just the Juju version that is changing?
[09:35] <mgz> we try to do that. there are obviously a few exceptions
[09:36] <mgz> maas can randomly pick different things to deploy on. here we have to use different bundles due to the format change, but they are roughly equivalent
[09:36] <mgz> so, what we talked about yesterday in our standup,
[09:37] <mgz> was making at least one of these deployer jobs have constraints so it only deploys on maas nodes with simple nic setup
[09:37] <mgz> so we don't lose all coverage of bundle deployment on maas due to this issue for now
[09:37] <jam> well ultimately it would suck to not support more than one network card as we roll out our big "network model" release.
[09:38] <jam> but we may have to do that in the short term.
[09:39] <jam> mgz: my concern is that we want to enable it as soon as we do have support
[09:39] <jam> adding workarounds tend to end up left there
[09:41] <dimitern> I'd appreciate a review on this really short and simple PR: http://reviews.vapour.ws/r/4019/
[09:41] <dimitern> mgz, hey, can we have a chat about that br-eth1 bug?
[09:42] <mgz> dimitern: see backscroll :)
[09:43] <dimitern> jam, exactly my point fwiw - too early to depend on br-eth1 will work
[09:43] <jam> dimitern: yeah, the shame is that "default-gateway" from 1.25 was sufficient for this, so we are regressing
[09:44] <dimitern> mgz, jam, there is a regression with 1.25 vs master with more than one container bridge, sure - but it's being worked on
[09:45] <jam> dimitern: what is "Empty" vs "IsNil" ?
[09:45] <dimitern> and since I'm practically the only one working on it, it will take a few days
[09:46] <dimitern> jam, well, I needed a schema.StringMap() that doesn't allow empty keys, and doesn't allow non-nil values as well.. so this came abotu
[09:46] <jam> dimitern: your coerce makes it look like the error you get is that if something isn't empty it tells you it is empty
[09:47] <jam> am I reading that correctly?
[09:48] <perrito666> morning
[09:48] <dimitern> jam, which test are you referring to?
[09:49] <jam> morning perrito666
[09:49] <jam> dimitern: I was just reading it wrong. Seems label is what goes in "expected".
[09:49] <dimitern> perrito666, morning fellow OCR ;)
[09:50] <dimitern> jam, ah, well - comments / suggestions are welcome :)
[09:54] <jam> dimitern: commented
[09:59] <frobware> dimitern, mgz, jam: once possibility for the br-ethX bug is that we don't bridge all interfaces until we land dimiter's changes.
[10:00]  * frobware continues that possibility in standup
[10:00] <voidspace> frobware: dimitern: dooferlad: dealing with son - be a few minutes late to standup
[10:01] <dimitern> jam, thanks!
[10:27] <dimitern> jam, thanks for the review, replied to all issues
[10:33] <dimitern> frobware, got latest master and did go instal ghc/j/j/... now waiting for make check to finish and will see how bad's the merge
[10:35] <frobware> dimitern: any conflicts?
[10:35] <dimitern> perrito666, can you have a look at http://reviews.vapour.ws/r/4019/ while jam's back please?
[10:35] <dimitern> frobware, will know in a few minutes, but a cursory diff against maas-spaces2 seems clean enough
[10:41] <frobware> dimitern, voidspace: http://reviews.vapour.ws/r/4021/
[10:41] <dimitern> frobware, looking
[10:45] <dimitern> frobware, no conflicts btw \o/
[10:45] <frobware> dimitern: great
[10:47] <dimitern> frobware, as soon as make check is done I'm proposing it
[10:49] <frobware> dimitern: thanks for the review
[10:49] <dimitern> frobware, LGTM
[10:49] <dimitern> :)
[10:50] <frobware> dimitern: I think we should take that into maas-spaces2, want to wait for it to merge in master?
[10:50] <mgz> $ ~/go/bin/juju version
[10:50] <mgz> 2.0-beta2-vivid-armhf
[10:51] <mgz> well, that was a pain
[10:51] <dimitern> frobware, let's not merge it into maas-spaces2 yet I think
[10:51] <frobware> dimitern: fair enough, but if xenial deployment is gating in CI then maas-spaces2 will fail.
[10:52] <dimitern> frobware, that's ok for the time being I guess, if it's the only thing remaining even better :)
[10:55] <perrito666> dimitern: hey, just came to the computer, lemme see
[10:56] <dimitern> perrito666, tyvm! I've said I'll rename Empty to Nil, but haven't pushed that yet - will do in a few minutes
[10:58]  * dimitern haven't seen 2 make check runs in a row to both succeed in quite some time now..
[11:00] <dimitern> voidspace, frobware, here's the merge - since there were neither test failures nor conflicts, I vote to just $$merge$$ it
[11:01] <dimitern> https://github.com/juju/juju/pull/4583
[11:02] <frobware> dimitern: agreed.
[11:03] <frobware> dimitern: go for the hat-trick :)
[11:03]  * dimitern types $$merge$$ and hits comment
[11:03] <voidspace> cool
[11:03] <dimitern> :)
[11:03] <perrito666> dimitern: ship it
[11:04] <jam> mgz: so what is going to be the best way to fix things for platforms I don't have (ppc, arm64, etc)
[11:04]  * perrito666 tries to ingest some sort of caffeine
[11:04] <dimitern> perrito666, jam, cheers!
[11:05] <mgz> jam: ppc64 and arm64 is probably easiest using the machines CI has
[11:06] <mgz> there are credentials for the stilsons and the new arm bits in cloud-city
[11:06] <jam> mgz: so is that grabbing cloud-city and going to town? or what's the handshake around that?
[11:07] <mgz> and yeah, say on irc that you're using a machine for informational purposes
[11:08] <mgz> you're unlikely to clash with active CI runs/the release process anyway
[11:08] <mgz> but can ask if unsure
[11:19] <frobware> jam: curious as to why you think we'd move to only bridging a single NIC as the default -- assuming I read that (email) correctly.
[11:41] <dimitern> perrito666, frobware, voidspace, jam, please have a look when you can at the next PR in line: https://github.com/juju/charm/pull/191 - extra-bindings in metadata
[11:41] <jam> frobware: that we're moving to bridging *all* NICs as default
[11:42] <jam> was what I was intending to say.
[11:42] <jam> frobware: I thought that was what you were proposing as a "fix"
[11:42] <jam> was it not?
[11:43] <jam> dimitern: the extra-bindings names should *not* be the same as peer relations
[11:43] <jam> we went with option 1
[11:43] <jam> which is all relations implicitly have bindings.
[11:44] <dimitern> jam, how about provides/requires ?
[11:44] <jam> dimitern: btw, my original confusion with "Empty" was because I thought it was a GoCheck Checker not a Schema one.
[11:44] <jam> dimitern: right all relations have a binding
[11:44] <frobware> jam: my proposed fix was to bridge 1 nic (agreed). but the way I read your email implied that would be our ongoing fix. perhaps I just misinterpreted that.
[11:45] <dimitern> jam, I suspected as much :)
[11:45] <jam> if we went with plain "bindings" then it would be you could list matching ones, but since we are doing "extra-bindings" you really should only specify ones that aren't listed elsewhere, I think.
[11:45] <dimitern> jam, ah, got you
[11:45] <jam> frobware: ah, it is "Reverting all" I missed the word reverting.
[11:46] <jam> frobware: do we know why it breaks if all of the containers are bridged? That seems odd.
[11:46] <jam> is it that the containers don't get the right default gateways to match the host?
[11:46] <dimitern> jam, that makes sense, so the PR should include tests ensuring extra bindings names do not match relation names?
[11:46] <jam> dimitern: yes. I think it is a charm schema failure if you duplicate the names.
[11:47] <frobware> jam: don't know. was trying to reproduce to understand and validate the proposal to revert to just one bridged nic.
[11:48] <jam> frobware: sure
[11:48] <dimitern> jam, that wasn't clear to me from the spec, but now it is, thanks - will adapt the PR accordingly
[11:54] <jam> mgz: just to confirm with you, is it ok if I create a development directory on stilson-05 to try to reproduce some of the test failures on ppc ?
[11:57] <jam> cherylj: I believe that tych0's patch does help with the CI regressions: github.com/juju/juju/pull/4564
[11:57] <jam> I'm just hesitant to land it myself since I broke stuff the last time I did that.
[12:07] <perrito666> my first OCR day without coffee is hell
[12:17] <dimitern> jam, frobware, updated https://github.com/juju/charm/pull/191 as discussed earlier
[12:32] <frobware> dimitern: any chance you could drop on to the standup HO?
[12:33] <dimitern> frobware, yeah, omw in 2m
[13:07] <jam> perrito666: well clearly you should get coffee then
[13:21] <marcoceppi> cherylj katco are resources in beta1?
[13:31] <mgz> jam: sorry, was out for lunch, yeah, create a new dir in home, set GOPATH to it, is what I normally do, pull tarball from reports.vapour.ws as needed
[13:31] <jam> mgz: it has limited network connectivity, right?
[13:32] <mgz> jam: it should be able to reach out to streams.canonical.com etc
[13:40] <rick_h__> marcoceppi: yes asked ger yesterday and it's there
[13:41] <rick_h__> marcoceppi: uogrwde i think will be in beta2
[13:41] <rick_h__> upgrade that is
[13:41] <marcoceppi> kk
[13:42] <urulama> resources in local only, that is.
[13:42] <rick_h__> marcoceppi: we want to see if there's a good charm to enable resources in with beta2 and get a joint blog/email to the list between her folks and someone on your team marcoceppi
[13:43] <rick_h__> marcoceppi: not sure if any good targets are in flight
[13:43] <rick_h__> urulama: yes, local only atm
[13:43] <marcoceppi> rick_h__: well I have a usecase for it for 2.0
[13:43] <marcoceppi> and want to be able to test it out
[13:43] <rick_h__> marcoceppi: cool
[13:43] <marcoceppi> local is fine
[13:44] <rick_h__> marcoceppi: i've asked them.to reach out to get a good real world.use case put together in the next couple of weeks so awesome
[13:44] <marcoceppi> rick_h__: how about dtag, that a good enough use case ;)
[13:44] <rick_h__> marcoceppi: :)
[13:49] <dimitern> jam, frobware, voidspace, guys, sorry to be a pest, but I need to land this in order to continue with the last 2 remaining PRs for extra-bindings: https://github.com/juju/charm/pull/191
[13:52] <frobware> dimitern: looking
[13:53] <frobware> dimitern: is there a RB for this? I'm happy to comment in the PR, just asking as I didn't see one.
[13:54] <jam> dimitern: responded
[13:54] <jam> frobware: I thought the same, but it is vs "charm" not vs "juju" so no RB
[13:54] <dimitern> frobware, no, it didn't create a RB diff for it again for some reason
[13:55] <dimitern> jam, thanks!
[13:56] <frobware> jam: ah, was on autopilot. thx.
[13:56] <mup> Bug #1551743 opened: juju <command> --format {yaml,json} should be more verbose <juju-core:New> <https://launchpad.net/bugs/1551743>
[14:08] <frobware> dimitern: reviewed. only concerns are about the type assertions
[14:09] <dimitern> frobware, I've updated the comment with my original reply to jam's question - does it make better sense now?
[14:09] <dimitern> frobware, and thanks!
[14:12] <frobware> dimitern: yep, comment helps. thx.
[14:56] <mup> Bug #1551779 opened: New azure provider ignores agent mirrors <azure-provider> <regression> <streams> <juju-core:Triaged> <https://launchpad.net/bugs/1551779>
[15:32] <alexisb> frobware, I am on the hangout when you are ready
[15:32] <frobware> alexisb: omw
[16:03] <katco> sinzui: fyi: https://github.com/juju/juju/pull/4585
[16:04] <katco> sinzui: will we be able to merge after, or do we need another bless?
[16:06] <sinzui> katco: I not certain, was the merge simple?
[16:06] <katco> sinzui: very. 1 line conflict
[16:06] <katco> sinzui: and it was very obvious that feature-resources should have had the preferred change
[16:07] <sinzui> katco: great. let's merge once your feature branch is current
[16:07] <katco> sinzui: awesome, i'll let you know
[16:28] <natefinch> gah, what the heck?  gopkg.in/juju/charmrepo.v1/csclient/params/params.go:37: undefined: charm.Reference
[16:29] <ericsnow> natefinch: don't you mean charmrepo.v2-unstable?
[16:29] <natefinch> ericsnow: ahh.. that's probably goimports
[16:30] <ericsnow> natefinch: yeah, the default branch is v1...
[16:30] <natefinch> ericsnow: thanks for catching that.. would have taken me forever to notice that
[16:30] <ericsnow> natefinch: I've got my mind on the charm store and the charm store on my mind
[16:31] <katco> ericsnow: lol
[16:31] <natefinch> man, we have way too many packages called "testing"
[16:32] <ericsnow> natefinch: I've starting switching to the XXXtest naming convention (a la the stdlib)
[16:32] <katco> we really need a meta testing package to test for the number of testing packages present... like github.com/juju/juju/juju/testing/testing/tests_test.go
[16:32] <natefinch> lol
[16:32] <ericsnow> katco: I wish!
[16:33]  * natefinch shudders and adds code to export_test.go :/
[16:39] <mup> Bug #1551842 opened: Juju 2.0 Trunk launches disconnected nodes <juju-core:New> <https://launchpad.net/bugs/1551842>
[16:41] <cherylj> hey frobware, are you going to backport a fix for bug 1550306 to 1.25?
[16:42] <mup> Bug #1550306: 1.25.3 can't bootstrap xenial environments <landscape> <juju-core:Fix Committed by frobware> <juju-core 1.25:Triaged by frobware> <https://launchpad.net/bugs/1550306>
[16:43] <voidspace> dimitern: ping
[16:44] <natefinch> lol assertCharmsUplodaded
[16:44] <dimitern> voidspace, pong
[16:44] <voidspace> dimitern: never mind, scratch that
[16:44] <voidspace> dimitern: following a different trail
[16:44] <dimitern> voidspace, ok :)
[16:45] <mup> Bug #1551842 changed: Juju 2.0 Trunk launches disconnected nodes <juju-core:New> <https://launchpad.net/bugs/1551842>
[16:48] <katco> sinzui: https://github.com/juju/juju/pull/4585 there are no conflicts with master now
[16:49] <katco> ericsnow: natefinch: merged master into feature-resources again. consider rebasing.
[16:49] <sinzui> thank you katco
[16:49] <ericsnow> katco: thanks
[16:50] <natefinch> katco: huzzah, thanks for that
[16:52] <frobware> cherylj: yes, but was looking at a fix for bug #1549545 first
[16:53] <mup> Bug #1549545: Bundle deploys fail at lxc-start when bridge br-eth1 is created <ci> <deploy> <maas-provider> <test-failure> <juju-core:Triaged by frobware> <https://launchpad.net/bugs/1549545>
[16:53] <dimitern> natefinch, ericsnow, juju/charm.v6-unstable is broken since https://github.com/juju/charm/pull/189 due to not updating juju/utils deps I believe
[16:53] <cherylj> frobware: is it an easy backport?
[16:53] <frobware> cherylj: yes
[16:53] <cherylj> frobware: I'll give it a try
[16:54] <frobware> it's not a straight cherry pick
[16:54] <ericsnow> dimitern: k
[16:54] <mup> Bug #1551842 opened: Juju 2.0 Trunk launches disconnected nodes <juju-core:New> <https://launchpad.net/bugs/1551842>
[16:55] <katco> sinzui: please lmk when we're merged into master
[16:59] <frobware> cherylj: let me look at 1.25 - shouldn't take me too long.
[17:00] <cherylj> frobware: is the problem specific to xenial on maas?
[17:01] <frobware> cherylj: yes
[17:09] <frobware> cherylj: backport done - needs follow-up live testing on precise, trusty, wily and xenial. bbiab.
[17:13] <katco> natefinch: how difficult are those tests turning out to be?
[17:16] <natefinch> katco: blech.  I'm having to cargo cult a bunch of stuff from the deploy tests.  Those tests are internal and mine have to be external, due to circular imports, so I'm having to copy & paste a bunch (or edit hundreds of lines of test code to export the existing test infrastructure that was written non-exported).
[17:16] <cherylj> frobware: I can help with testing
[17:16] <natefinch> katco: that being said, I have the infrastructure working and can deploy starsay during tests with full charmstore support
[17:17] <katco> natefinch: well at least there's that :)
[17:17] <natefinch> katco: so, the hard part is mostly done, now I just have to write the actual tests, which shouldn't be too bad
[17:17] <katco> natefinch: yippee :D
[17:36] <mup> Bug #1551857 opened: juju 2.0 Beta1: ERROR zip: not a valid zip file while deploying invalid yaml bundle <oil> <juju-core:New> <https://launchpad.net/bugs/1551857>
[19:40] <natefinch> ug... the empty charmstore stuff is failing validation, so it kills my tests...feh.
[19:50] <natefinch> ericsnow: booooooo... was looking for the resource persistence stuff... remembered it lives in juju/state now :/
[19:51] <ericsnow> natefinch: gee, thanks for reminding me :P
[19:51] <natefinch> ericsnow: lol
[19:52] <ericsnow> natefinch: puzzling through the charmstore full-stack tests right now, so you got me at a cheerful moment <wink>
[19:53] <natefinch> ericsnow: hmm... this produces zero-value resources: https://github.com/juju/juju/blob/master/state/resources_persistence.go#L88
[19:53] <natefinch> ericsnow: (since there's no resources being returned from the store)
[19:53] <natefinch> ericsnow: which results in empty resources being put in the CharmStoreResources, which fail validation
[19:54] <ericsnow> natefinch: ah, crappy
[19:54] <ericsnow> natefinch: I was going to fix that and forgot
[19:55] <natefinch> ericsnow: this whole "write the client before the server exists" is kind of a giant PITA
[19:55] <ericsnow> natefinch: agreed
[19:57] <ericsnow> natefinch: as far as that bug goes, we need to be sure that we set the "store" resource at the same time we set the resource during deploy/upgrade-charm
[19:57] <perrito666> uff, I am tired of deprecating code
[20:03] <natefinch> ericsnow: I was pretty sure we're doing that... sure seems like it, but maybe I'm missing something
[20:13] <katco> ericsnow: natefinch: are you 2 able to do the standup half an hour earlier? wallyworld and i have a conflict
[20:16] <natefinch> katco: yep
[20:17] <ericsnow> katco: fine with me
[20:17] <katco> natefinch: ericsnow: ta
[20:18] <ericsnow> natefinch, katco: I'm so glad I have to run an actual elasticsearch server in order to run the charm store test suites! :P
[20:18] <wwitzel3> lol
[20:19] <katco> ericsnow: ....... ...
[20:19] <katco> ericsnow: i don't know what to say to that. it's obvious to at least me that this is non-optimal
[20:20] <natefinch> lol
[20:20] <ericsnow> katco: I'd better not say anything else
[20:20] <natefinch> obviously, elasticsearch has been finely tuned and optimized, so running any kind of a mock would be slower
[20:21] <wwitzel3> plus the format elasticsearch returns is just hard to mock
[20:21] <katco> wwitzel3: did you notice how we all just casually ignored you?
[20:21] <wwitzel3> pesky json
[20:22] <natefinch> katco: so, just like old times? ;)
[20:22] <katco> zing!
[20:22] <wwitzel3> yeah, natefinch nailed it, how is that any different :P
[20:23] <wwitzel3> I have a NLP plugin for my client that detects when ericsnow is being sarcastic and automatically sends a lol
[20:24] <perrito666> it is different in the fact that wwitzel3 does not have to deal with these tests :p
[20:24] <katco> wwitzel3: lol
[20:24] <natefinch> Must have a bug, since we haven't been spammed by lols ;)
[20:24] <ericsnow> wwitzel3: you need to tune it because I've been a lot more sarcastic lately and haven't see your lol <wink>
[20:25] <wwitzel3> hah, well there is consensus on that at least :)
[20:25] <katco> wwitzel3: i have been seriously concerned with the dangerously low level of tattoos on our team since you left. i'm trying to convince ericsnow to get a python facial tatt.
[20:25] <wwitzel3> neck is better
[20:26] <ericsnow> katco: forehead
[20:27] <katco> ericsnow: we can start calling you snake
[20:27] <katco> ericsnow: "snake, the gopher eater"
[20:27] <natefinch> really, after eric shaved his head and got the eyebrow piercing, I think all bets are off
[20:30] <natefinch> katco: these tests are going slower than expected... I think there's some bugs in the code that they're finding, but figuring out exactly where it is, is kinda slow going (since they're full stack tests.....)
[20:31] <katco> natefinch: want to hop in a hangout and pair?
[20:32] <natefinch> katco: sure thing
[20:32] <katco> natefinch: i'm just in moonstone. putting some water to boil on
[20:32] <katco> natefinch: rather, water on to boil
[20:32] <perrito666> katco: clearly moonstone hangout has better features than tanzanite, ours is only good for chatting
[20:33] <perrito666> :p
[20:35] <natefinch> katco: coming
[20:45] <katco> ericsnow: moonstone if you have a moment
[20:57] <thumper> menn0: http://reviews.vapour.ws/r/4008/ updated
[20:58] <thumper> menn0: also http://reviews.vapour.ws/r/4015/
[20:59] <thumper> menn0: would also like to talk about this new package for managing migration, and where to put it and what to call it
[21:04] <menn0> thumper: will look first
[21:04] <menn0> at reviews
[21:04] <menn0> and then talk?
[21:04] <thumper> sur
[21:04] <thumper> e
[21:13] <menn0> thumper: ship it (with 2 non-issues) for http://reviews.vapour.ws/r/4008/
[21:16] <thumper> menn0: cheers
[21:29] <menn0> thumper: ship it on the other one too
[21:42] <mup> Bug #1551959 opened: juju-tools 1.25.0 with juju-agent 1.25.3 has networking issues <juju-core:New> <https://launchpad.net/bugs/1551959>
[22:06] <mup> Bug #1465307 changed: 1.24.0: Lots of "agent is lost, sorry!" messages <landscape> <regression> <juju-core:New> <https://launchpad.net/bugs/1465307>