[00:33] software http://paste.ubuntu.com/15248178/ [00:36] beautiful [00:43] davecheney: ping [00:43] davecheney: I have []someDocType, and a method Insert(docs ...interface{}) [00:44] is there an easy way to squich the former into the latter? [00:44] cannot use docs (type []historicalStatusDoc) as type []interface {} in argument to statusHistory.Writeable().Insert [00:46] menn0: ^^ any ideas? [00:47] nm [00:47] found an easy soluntion [00:50] thumper: sorry i'm on my way out to run an errand [00:50] don't worry [00:50] all sorted [00:50] katco: cherylj as a formality, can you approve we want to merge feature-resources into master http://reviews.vapour.ws/r/4007/ [00:52] c.Check(importedHistory[i].Since, gc.Equals, exportedHistory[i].Since) [00:52] ... obtained *time.Time = &time.Time{sec:63592390248, nsec:901470923, loc:(*time.Location)(0x3fc4ec0)} ("2016-03-01 13:50:48.901470923 +1300 NZDT") [00:52] ... expected *time.Time = &time.Time{sec:63592390248, nsec:901470923, loc:(*time.Location)(0x3fc4ec0)} ("2016-03-01 13:50:48.901470923 +1300 NZDT") [00:52] who can spot the difference? [00:53] deepequals necessary? [00:55] yep [00:55] need jc.DeepEquals [00:59] sinzui: shipit! [00:59] thank you cherylj [01:00] ouch cherylj I cannot merge, sorry katco, feature-resources now conflicts with master https://github.com/juju/juju/pull/4569 [01:01] :( [01:33] thumper: http://reviews.vapour.ws/r/4009/ [01:34] davecheney: shipit [01:34] thumper: thanks [01:36] np [02:54] thumper: http://reviews.vapour.ws/r/4013/ [02:55] another one for you [03:31] thumper: http://reviews.vapour.ws/r/4014/ [04:12] * thumper is out now [04:12] probably back later tonight, because, you know, busy... [05:22] Hey thumper, look what we get noe [05:22] local error: bad record MAC [05:22] github.com/juju/juju/state/open.go:208: cannot create index [05:22] github.com/juju/juju/state/open.go:239: [05:22] github.com/juju/juju/state/open.go:83: [05:22] github.com/juju/juju/state/open.go:114: [09:26] mgz: bug 1549545 would be good to discuss when you're around [09:26] Bug #1549545: Bundle deploys fail at lxc-start when bridge br-eth1 is created

=== akhavr1 is now known as akhavr [09:26] jam, sure thing [09:29] jam: I thought from the previius chatter dimitern had a pretty good idea what was up [09:30] ...what is that... 'previius'? jesu [09:30] I think it is the Previous Prius [09:31] 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] ehehe [09:31] I thought bug #1549545 was preventing us from getting a blessed release [09:31] Bug #1549545: Bundle deploys fail at lxc-start when bridge br-eth1 is created

[09:31] and while it is a configuration we want to support, it wasn't supported in the past. [09:32] OR did we actually break a mode that was working previously? [09:32] 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] so we did regress vs 1.x behavior [09:33] we can release with the bug and put it in release notes, so it's not blocking as such [09:33] where we only supported 1, but we detected which was the default gateway [09:33] jam: yeah, see the history of the maas-1_9-deployer job say, 1.25 passes [09:34] 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] we try to do that. there are obviously a few exceptions [09:36] 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] so, what we talked about yesterday in our standup, [09:37] was making at least one of these deployer jobs have constraints so it only deploys on maas nodes with simple nic setup [09:37] so we don't lose all coverage of bundle deployment on maas due to this issue for now [09:37] well ultimately it would suck to not support more than one network card as we roll out our big "network model" release. [09:38] but we may have to do that in the short term. [09:39] mgz: my concern is that we want to enable it as soon as we do have support [09:39] adding workarounds tend to end up left there [09:41] I'd appreciate a review on this really short and simple PR: http://reviews.vapour.ws/r/4019/ [09:41] mgz, hey, can we have a chat about that br-eth1 bug? [09:42] dimitern: see backscroll :) [09:43] jam, exactly my point fwiw - too early to depend on br-eth1 will work [09:43] dimitern: yeah, the shame is that "default-gateway" from 1.25 was sufficient for this, so we are regressing [09:44] 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] dimitern: what is "Empty" vs "IsNil" ? [09:45] and since I'm practically the only one working on it, it will take a few days [09:46] 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] 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] am I reading that correctly? [09:48] morning [09:48] jam, which test are you referring to? [09:49] morning perrito666 [09:49] dimitern: I was just reading it wrong. Seems label is what goes in "expected". [09:49] perrito666, morning fellow OCR ;) [09:50] jam, ah, well - comments / suggestions are welcome :) [09:54] dimitern: commented [09:59] 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] frobware: dimitern: dooferlad: dealing with son - be a few minutes late to standup [10:01] jam, thanks! [10:27] jam, thanks for the review, replied to all issues [10:33] 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] dimitern: any conflicts? [10:35] perrito666, can you have a look at http://reviews.vapour.ws/r/4019/ while jam's back please? [10:35] frobware, will know in a few minutes, but a cursory diff against maas-spaces2 seems clean enough [10:41] dimitern, voidspace: http://reviews.vapour.ws/r/4021/ [10:41] frobware, looking [10:45] frobware, no conflicts btw \o/ [10:45] dimitern: great [10:47] frobware, as soon as make check is done I'm proposing it [10:49] dimitern: thanks for the review [10:49] frobware, LGTM [10:49] :) [10:50] dimitern: I think we should take that into maas-spaces2, want to wait for it to merge in master? [10:50] $ ~/go/bin/juju version [10:50] 2.0-beta2-vivid-armhf [10:51] well, that was a pain [10:51] frobware, let's not merge it into maas-spaces2 yet I think [10:51] dimitern: fair enough, but if xenial deployment is gating in CI then maas-spaces2 will fail. [10:52] frobware, that's ok for the time being I guess, if it's the only thing remaining even better :) [10:55] dimitern: hey, just came to the computer, lemme see [10:56] 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.. === rvba` is now known as rvba [11:00] voidspace, frobware, here's the merge - since there were neither test failures nor conflicts, I vote to just $$merge$$ it [11:01] https://github.com/juju/juju/pull/4583 [11:02] dimitern: agreed. [11:03] dimitern: go for the hat-trick :) [11:03] * dimitern types $$merge$$ and hits comment [11:03] cool [11:03] :) [11:03] dimitern: ship it [11:04] 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] perrito666, jam, cheers! [11:05] jam: ppc64 and arm64 is probably easiest using the machines CI has [11:06] there are credentials for the stilsons and the new arm bits in cloud-city [11:06] mgz: so is that grabbing cloud-city and going to town? or what's the handshake around that? [11:07] and yeah, say on irc that you're using a machine for informational purposes [11:08] you're unlikely to clash with active CI runs/the release process anyway [11:08] but can ask if unsure [11:19] 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] 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] frobware: that we're moving to bridging *all* NICs as default [11:42] was what I was intending to say. [11:42] frobware: I thought that was what you were proposing as a "fix" [11:42] was it not? [11:43] dimitern: the extra-bindings names should *not* be the same as peer relations [11:43] we went with option 1 [11:43] which is all relations implicitly have bindings. [11:44] jam, how about provides/requires ? [11:44] dimitern: btw, my original confusion with "Empty" was because I thought it was a GoCheck Checker not a Schema one. [11:44] dimitern: right all relations have a binding [11:44] 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] jam, I suspected as much :) [11:45] 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] jam, ah, got you [11:45] frobware: ah, it is "Reverting all" I missed the word reverting. [11:46] frobware: do we know why it breaks if all of the containers are bridged? That seems odd. [11:46] is it that the containers don't get the right default gateways to match the host? [11:46] jam, that makes sense, so the PR should include tests ensuring extra bindings names do not match relation names? [11:46] dimitern: yes. I think it is a charm schema failure if you duplicate the names. [11:47] jam: don't know. was trying to reproduce to understand and validate the proposal to revert to just one bridged nic. [11:48] frobware: sure [11:48] jam, that wasn't clear to me from the spec, but now it is, thanks - will adapt the PR accordingly [11:54] 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] cherylj: I believe that tych0's patch does help with the CI regressions: github.com/juju/juju/pull/4564 [11:57] I'm just hesitant to land it myself since I broke stuff the last time I did that. [12:07] my first OCR day without coffee is hell [12:17] jam, frobware, updated https://github.com/juju/charm/pull/191 as discussed earlier [12:32] dimitern: any chance you could drop on to the standup HO? [12:33] frobware, yeah, omw in 2m [13:07] perrito666: well clearly you should get coffee then === akhavr1 is now known as akhavr [13:21] cherylj katco are resources in beta1? [13:31] 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] mgz: it has limited network connectivity, right? [13:32] jam: it should be able to reach out to streams.canonical.com etc [13:40] marcoceppi: yes asked ger yesterday and it's there [13:41] marcoceppi: uogrwde i think will be in beta2 [13:41] upgrade that is [13:41] kk [13:42] resources in local only, that is. [13:42] 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] marcoceppi: not sure if any good targets are in flight [13:43] urulama: yes, local only atm [13:43] rick_h__: well I have a usecase for it for 2.0 [13:43] and want to be able to test it out [13:43] marcoceppi: cool [13:43] local is fine [13:44] 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] rick_h__: how about dtag, that a good enough use case ;) [13:44] marcoceppi: :) [13:49] 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] dimitern: looking [13:53] dimitern: is there a RB for this? I'm happy to comment in the PR, just asking as I didn't see one. === Spads_ is now known as Spads [13:54] dimitern: responded [13:54] frobware: I thought the same, but it is vs "charm" not vs "juju" so no RB [13:54] frobware, no, it didn't create a RB diff for it again for some reason [13:55] jam, thanks! [13:56] jam: ah, was on autopilot. thx. [13:56] Bug #1551743 opened: juju --format {yaml,json} should be more verbose [14:08] dimitern: reviewed. only concerns are about the type assertions [14:09] frobware, I've updated the comment with my original reply to jam's question - does it make better sense now? [14:09] frobware, and thanks! [14:12] dimitern: yep, comment helps. thx. === akhavr1 is now known as akhavr === cmars` is now known as cmars [14:56] Bug #1551779 opened: New azure provider ignores agent mirrors

[15:32] frobware, I am on the hangout when you are ready [15:32] alexisb: omw === rcj` is now known as rcj [16:03] sinzui: fyi: https://github.com/juju/juju/pull/4585 [16:04] sinzui: will we be able to merge after, or do we need another bless? [16:06] katco: I not certain, was the merge simple? [16:06] sinzui: very. 1 line conflict [16:06] sinzui: and it was very obvious that feature-resources should have had the preferred change [16:07] katco: great. let's merge once your feature branch is current [16:07] sinzui: awesome, i'll let you know === akhavr1 is now known as akhavr [16:28] gah, what the heck? gopkg.in/juju/charmrepo.v1/csclient/params/params.go:37: undefined: charm.Reference [16:29] natefinch: don't you mean charmrepo.v2-unstable? [16:29] ericsnow: ahh.. that's probably goimports [16:30] natefinch: yeah, the default branch is v1... [16:30] ericsnow: thanks for catching that.. would have taken me forever to notice that [16:30] natefinch: I've got my mind on the charm store and the charm store on my mind [16:31] ericsnow: lol [16:31] man, we have way too many packages called "testing" [16:32] natefinch: I've starting switching to the XXXtest naming convention (a la the stdlib) [16:32] 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] lol [16:32] katco: I wish! [16:33] * natefinch shudders and adds code to export_test.go :/ [16:39] Bug #1551842 opened: Juju 2.0 Trunk launches disconnected nodes [16:41] hey frobware, are you going to backport a fix for bug 1550306 to 1.25? [16:42] Bug #1550306: 1.25.3 can't bootstrap xenial environments

[16:43] dimitern: ping [16:44] lol assertCharmsUplodaded [16:44] voidspace, pong [16:44] dimitern: never mind, scratch that [16:44] dimitern: following a different trail [16:44] voidspace, ok :) [16:45] Bug #1551842 changed: Juju 2.0 Trunk launches disconnected nodes [16:48] sinzui: https://github.com/juju/juju/pull/4585 there are no conflicts with master now [16:49] ericsnow: natefinch: merged master into feature-resources again. consider rebasing. [16:49] thank you katco [16:49] katco: thanks [16:50] katco: huzzah, thanks for that [16:52] cherylj: yes, but was looking at a fix for bug #1549545 first [16:53] Bug #1549545: Bundle deploys fail at lxc-start when bridge br-eth1 is created

[16:53] 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] frobware: is it an easy backport? [16:53] cherylj: yes [16:53] frobware: I'll give it a try [16:54] it's not a straight cherry pick [16:54] dimitern: k [16:54] Bug #1551842 opened: Juju 2.0 Trunk launches disconnected nodes [16:55] sinzui: please lmk when we're merged into master [16:59] cherylj: let me look at 1.25 - shouldn't take me too long. [17:00] frobware: is the problem specific to xenial on maas? [17:01] cherylj: yes [17:09] cherylj: backport done - needs follow-up live testing on precise, trusty, wily and xenial. bbiab. [17:13] natefinch: how difficult are those tests turning out to be? [17:16] 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] frobware: I can help with testing [17:16] katco: that being said, I have the infrastructure working and can deploy starsay during tests with full charmstore support [17:17] natefinch: well at least there's that :) [17:17] 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] natefinch: yippee :D [17:36] Bug #1551857 opened: juju 2.0 Beta1: ERROR zip: not a valid zip file while deploying invalid yaml bundle

=== mpontillo_ is now known as mpontillo [19:40] ug... the empty charmstore stuff is failing validation, so it kills my tests...feh. === JoseeAntonioR is now known as jose [19:50] ericsnow: booooooo... was looking for the resource persistence stuff... remembered it lives in juju/state now :/ [19:51] natefinch: gee, thanks for reminding me :P [19:51] ericsnow: lol [19:52] natefinch: puzzling through the charmstore full-stack tests right now, so you got me at a cheerful moment [19:53] ericsnow: hmm... this produces zero-value resources: https://github.com/juju/juju/blob/master/state/resources_persistence.go#L88 [19:53] ericsnow: (since there's no resources being returned from the store) [19:53] ericsnow: which results in empty resources being put in the CharmStoreResources, which fail validation [19:54] natefinch: ah, crappy [19:54] natefinch: I was going to fix that and forgot [19:55] ericsnow: this whole "write the client before the server exists" is kind of a giant PITA [19:55] natefinch: agreed [19:57] 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] uff, I am tired of deprecating code [20:03] ericsnow: I was pretty sure we're doing that... sure seems like it, but maybe I'm missing something [20:13] ericsnow: natefinch: are you 2 able to do the standup half an hour earlier? wallyworld and i have a conflict [20:16] katco: yep [20:17] katco: fine with me [20:17] natefinch: ericsnow: ta [20:18] 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] lol [20:19] ericsnow: ....... ... [20:19] ericsnow: i don't know what to say to that. it's obvious to at least me that this is non-optimal [20:20] lol [20:20] katco: I'd better not say anything else [20:20] obviously, elasticsearch has been finely tuned and optimized, so running any kind of a mock would be slower [20:21] plus the format elasticsearch returns is just hard to mock [20:21] wwitzel3: did you notice how we all just casually ignored you? [20:21] pesky json [20:22] katco: so, just like old times? ;) [20:22] zing! [20:22] yeah, natefinch nailed it, how is that any different :P [20:23] I have a NLP plugin for my client that detects when ericsnow is being sarcastic and automatically sends a lol [20:24] it is different in the fact that wwitzel3 does not have to deal with these tests :p [20:24] wwitzel3: lol [20:24] Must have a bug, since we haven't been spammed by lols ;) [20:24] wwitzel3: you need to tune it because I've been a lot more sarcastic lately and haven't see your lol [20:25] hah, well there is consensus on that at least :) [20:25] 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] neck is better [20:26] katco: forehead [20:27] ericsnow: we can start calling you snake [20:27] ericsnow: "snake, the gopher eater" [20:27] really, after eric shaved his head and got the eyebrow piercing, I think all bets are off [20:30] 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] natefinch: want to hop in a hangout and pair? [20:32] katco: sure thing [20:32] natefinch: i'm just in moonstone. putting some water to boil on [20:32] natefinch: rather, water on to boil [20:32] katco: clearly moonstone hangout has better features than tanzanite, ours is only good for chatting [20:33] :p [20:35] katco: coming [20:45] ericsnow: moonstone if you have a moment [20:57] menn0: http://reviews.vapour.ws/r/4008/ updated [20:58] menn0: also http://reviews.vapour.ws/r/4015/ [20:59] 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] thumper: will look first [21:04] at reviews [21:04] and then talk? [21:04] sur [21:04] e [21:13] thumper: ship it (with 2 non-issues) for http://reviews.vapour.ws/r/4008/ [21:16] menn0: cheers [21:29] thumper: ship it on the other one too [21:42] Bug #1551959 opened: juju-tools 1.25.0 with juju-agent 1.25.3 has networking issues === natefinch is now known as natefinch-voting [22:06] Bug #1465307 changed: 1.24.0: Lots of "agent is lost, sorry!" messages