[01:35] i'm going to mark 1488581 as Fix Released. Thanks to cherylj's change, the broken test is now passing against in jenkins. [01:35] bug 1488581 [01:35] Bug #1488581: TestFindToolsExactInStorage fails for some archs

[01:35] menn0: cherylj: tyvm!! [01:36] master is unblocked again [01:45] master cannot be unblcked without a bless [01:46] PS I just forced a retest to help master get a bless. [01:50] sinzui: \o/ tyvm [02:14] sinzui: sorry [02:14] you are forgiven menn0 [02:15] only one job left, then I can sleep [02:47] Bug #1488581 changed: TestFindToolsExactInStorage fails for some archs

[03:22] wallyworld: the `storage: add volume status to "juju storage volume list"` card *was* done [03:22] just checked, it's in master [03:22] moving card from review to previous [03:22] axw_: awesome, wanna add a sentence to the release notes? [03:22] wallyworld: will do [03:22] ty [03:28] wow [03:28] ./worker/... tests take > 40 minutes to run on ppc64 [03:29] davecheney: how much is uniter? [03:29] > 600 seconds [03:29] timed out [03:29] heh [06:20] http://reviews.vapour.ws/r/2483/ [06:20] this fixes the patch that cherylj landed earlier [06:20] not that her's was wrong [06:20] this is just the proper fix [06:41] Bug #1488777 opened: Add a wait command [07:43] http://reviews.vapour.ws/r/2484/ [07:43] ping [08:16] is there a pretty way in golang to insert a slice of strings in the middle of another slice? [08:16] davechen1y ^^ [08:18] bogdanteleaga, https://github.com/golang/go/wiki/SliceTricks [08:20] I guess it's a = append(a[:i], append(b, a[i:]...)...), wouldn't call it pretty tho [08:32] voidspace, TheMue, http://reviews.vapour.ws/r/2486/ please take a look - provisioning support for spaces constraints [08:34] bogdanteleaga, the beauty is within :D [08:37] haha [08:38] dimitern: looking [08:40] hmmm... coffee first [08:40] dimitern: the travel provider booked me tickets from London to Northampton, and then on the friday back from Northampton to London... [08:40] oops [08:40] dimitern: they're buying me new tickets now (for the sprint) [08:42] voidspace, ok, so all will be sorted out soon hopefully :) [08:44] dimitern: could you tell me why machineSubnetsAndZones() only uses includeSpaces[0]? (or do I'm looking wrong?) [08:45] TheMue, there is a comment about it [08:45] TheMue, for the MVP work we only use the first positive space and ignore the rest [08:46] dimitern: yeah, read it. but why? simply helping me to understand it. it's a new topic for me. ;) [08:48] TheMue, for simplicity [08:48] TheMue, we want a *minimal* viable product :) [08:48] dimitern: ok, sounds good :) [08:49] TheMue, once we can do deployments within a single space reliably, it shouldn't be much of a problem do expand this to multiple spaces [08:50] dimitern: thx [08:52] dimitern: you've got a review [08:53] TheMue, thanks! [08:59] dimitern: will be a couple of minutes late to standup - on the phone :-/ [08:59] voidspace, sure [09:07] dimitern: lost connection - rejoining [09:10] dimitern: lost connection again - rejoining [09:11] dimitern: struggling to rejoin apparently [09:18] dimitern: dammit - connection lost again [09:19] dimitern: my suggestion is that we store a default, but when the address is requested we look at whether it is an exact match for scope & type [09:19] dimitern: if it isn't an exact match we check for a better match and if there is one we return that and change the default address [09:20] dimitern: so we always return the same one until / unless a better match is found - and then we always return that one [09:20] dimitern: so we *can* change address - but only if we were using a fallback scope or type [09:20] dimitern: does that sound like a reasonable algorithm? [09:21] I can add it as a comment on the bug to give Ed a chance to comment [09:25] voidspace, yes, that sounds good [09:25] dimitern: cool [09:26] voidspace, just to summarize the chat so far: we need a default address (per scope most likely), and a way to only select an exact match per scope [09:28] dimitern: where "per scope" is private / public [09:28] voidspace, when we don't have a default address yet, just pick the first one; later if we have more than 1 exact match, use the previously stored default [09:28] dimitern: but yes [09:28] dimitern: yes [09:28] dimitern: the algorithm looks like this [09:28] dimitern: first time requested use the first "match" using the current algorithm [09:28] dimitern: subsequent requests, check if the stored default is an exact match - if it is *always* use it [09:29] dimitern: if the default isn't an exact match check if an exact match is now available [09:29] dimitern: if not, use the current default (so we remain stable) [09:29] dimitern: if an exact match is available, store that as the default and use that [09:29] dimitern: subsequent requests will now always see the new default [09:30] voidspace, how can a previous default address both still exist and not be an exact match? [09:31] dimitern: because if there isn't an exact match on scope / type we allow fallbacks === anthonyf is now known as Guest39525 [09:31] dimitern: e.g. if preferipv6 is on we can return an ipv4 address if an ipv6 one isn't available [09:31] voidspace, ah, because the previous default might have been a fallback [09:32] dimitern: so the first part is "if an exact match isn't available still store the fallback as default" [09:32] dimitern: to ensure we always return the same one unless / until an exact match is available [09:33] voidspace, that all sounds sane to me, but let's add it to the bug and ask dosaboy how does it sound to him [09:35] voidspace, also, I'd appreciate a review on my PR :) [09:37] dimitern: ok, I've written up my suggestion on the bug and will switch to your PR now [09:38] voidspace, cheers! [09:47] trivial review anyone (no logic changes, just a data change): https://github.com/juju/juju/pull/3110 [09:48] dimitern: exactly duplicated test setup code in api and apiserver :-/ [09:48] voidspace, it's not quite duplicated :) [09:49] voidspace, but fair point - it can be put in a common place [09:49] voidspace, state/testing ? [09:49] dimitern: sounds good. [09:52] dimitern: your call [09:52] dimitern: for *two* use cases it's barely worth it [09:52] dimitern: for three it would definitely be worth it [09:53] dimitern: I won't add it as an issue on the PR, just noting it [09:53] voidspace, the duplication was bugging me as well, but wanted to make it work first, then polish [09:53] voidspace, ok [09:57] s.checkStartInstanceCustom(c, m, "pork", s.defaultConstraints, nil, nil, nil, nil, false, nil, true) [09:57] nil, nil, nil, nil, false, nil, true [09:57] self documenting code be damned! [10:01] dimitern: ah, so this PR only adds support into the dummy provider [10:01] dimitern: EC2 will be a follow up [10:01] I was looking for where the new mapping was actually used! [10:02] anyway, looks ok to me - dependent on the EC2 support of course [10:06] voidspace, yeah, it had to include the dummy provider support [10:06] voidspace, thanks, will update with the suggestions and set it to land [10:07] cool [10:46] morning [11:27] * fwereade wishes he'd learn to follow his own advice -- dependency.Engine would be much easier to test in pathological cases if I'd thought to write the algorithm without the concurrency [11:28] fwereade: you can tell your self you told you so [12:37] dimitern: btw, your testing stub for spaces is very tricky, but nice. needed some time to get it, now doing the final changes here to handle then enabling and disabling of SupportsSpaces [12:38] TheMue, awesome! [12:40] dimitern: but this leads to a more general proposal. each package should have a doc.go containing only the package statement but above a description about the intention and usage of the package. so it is visible e.g. on godoc.org as well as it is easy to jump into new packages [12:47] TheMue, this is unrelated, but I like it [12:47] TheMue, we should bring it up on the ML for discussion [12:51] dimitern: yep, will do so [13:54] cherylj: is master waiting for a merges to release 1.25-alpha1? or are we waiting on the 3 untested revisions? http://reports.vapour.ws/releases/3008 is bless, but is 3 merges behind tip [13:54] ericsnow: thanks for the review of my untrack cmd code. I responded to a bunch of stuff, but haven't started actually modifying the code yet. [13:54] natefinch: cool [14:15] voidspace, hey, how goes the forward port btw? [14:16] dimitern, do you have time to HO for build/test related stuff? [14:19] frobware, I do, just give me 10m ? [14:19] dimitern, np [14:24] dimitern: per my question in channel earlier, is master waiting for a merges to release 1.25-alpha1? or are we waiting on the 3 untested revisions? http://reports.vapour.ws/releases/3008 is bless, but is 3 merges behind tip [14:25] dimitern: also Lp wont let me update bug 1488576 at the moment. It is a rising problem in the test suite [14:25] Bug #1488576: TestAddresserWorkerStopsWhenAddressDeallocationNotSupported fails on pp64el

[14:26] sinzui, I have one PR with I'll set to land in 2 minutes [14:26] sinzui, re that bug - I vote to skip it on ppc64 [14:27] dimitern: Ci sees it everyewhere, but is ppc64el most http://reports.vapour.ws/releases/issue/55d89569749a56415476f23b [14:29] sinzui, so if we disable it on ppc64, it should improve things for the time being? [14:30] yes, but we still risk failure on some other arch until we fix the test [14:32] sinzui, agreed, I'll look into it tomorrow [14:32] :) [14:34] sinzui, actually, I'm seeing failures even locally [14:34] sinzui, I'll disable it entirely then [14:34] ericsnow: found my bug :) [14:34] sinzui, then tomorrow will dig into it some more [14:35] dimitern: yeah. when I first found the bug, it was only on ppc64el. we now have several runs and see it everywhere. That is was I was trying to say in the bug when Lp was giving who timeouts [14:35] ericsnow: I didn't remove the Workloads list from the meta struct in the charm library and our Definitions call loops through meta.Workloads (which was empty) [14:36] dimitern: once your current PR is merges (assuming a bless) do we haver all the features in place for a release? [14:38] sinzui, I have no others of mine [14:39] sinzui, and I believe nothing critical remains from our stuff [14:39] thank you dimitern [14:40] frobware, *whew* sorry for the delay, let's get in a HO now? [14:43] dimitern, ok [14:46] wwitzel3: ah, glad you caught that [15:08] hey core guys, there's an email on the main juju list with some issues around huge mongodb, odd errors, and 4+gb log files Could someone take a look? [15:08] hey core guys and gals* [15:08] hey core ppl* [15:09] pc fail [15:09] actually trying to break old habbits of calling everyone guys [15:09] er... as in 'politial correctness' [15:10] * marcoceppi is not sloth [15:10] it's good to try :) [15:10] I basically think of guys as gender neutral these days, it's how it seems to be used [15:11] I've seen women using it to address a mixed group, but I guess not a all-female group [15:11] I use it to address my lady-friends [15:12] * katco thinks guys is fine and uses it to address my lady-friends as well [15:12] y'all [15:12] or all-y'all [15:12] natefinch: personally hate that colloquialism [15:12] katco: lol me too [15:12] I don't think I've ever used y'all un-ironically [15:13] and I'm from texas, y'all! [15:13] lol [15:13] I made someone mad over the weekend by using guys in my typical gender neutral fashion, so peeps is it from now on [15:13] eheheh [15:13] cherylj: me either, but I'm a Yankee [15:13] I use peeps ironically, except sometimes I forget the irony [15:13] heh [15:13] everything I say is ironic [15:13] even that! [15:14] anyways, core peeps, there's that email, I'm not sure what to tell him over then "try to upgrade your production openstack environment to use juju 1.24.5" [15:19] marcoceppi: looking [15:24] natefinch: thanks! [15:27] marcoceppi: first thought is that it might be networking problems. timeouts usually mean networking [15:50] dimitern: cherylj : are you happy with master tip? Is this waht you want to release? Ci will test this soon: https://github.com/juju/juju/commits/master [15:51] sinzui: that works for me, but I don't know if there are other merges we're waiting on. [15:51] cmars, katco, are there things you're wanting in 1.25-alpha1? [15:51] ^ katco are you really hear to call the cut of 1.25-alpha1? [15:51] here [15:52] Bug #1489053 opened: rabbitmq-server charm fails on cluster-relation-changed when using openstack provider [15:52] sinzui: i'm here [15:52] cherylj: sinzui: sorry been out sick... moonstone didn't have anything for 1.25 [15:54] Hey! I have an idle juju machine with a charm deployed on it. Everytime I reboot the machine, config-changed gets executed when machine comes up. I pressume this is the normal behaviour, right ? [15:57] ionutbalutoiu: I believe so. config-changed hooks get run a lot. The code in them should be written with that in mind. [16:09] dimitern: oh yeah, meant to tell you - sorry [16:09] dimitern: it's already on master [16:22] Bug #1489053 changed: rabbitmq-server charm fails on cluster-relation-changed when using openstack provider [16:23] natefinch: for bugfixes, which branch should we target? [16:23] 1.24? [16:23] natefinch: nice haircut by the way [16:35] voidspace: thanks [16:35] voidspace: uh... bug fixes for what? [16:38] natefinch: I am working on a juju-core bug [16:38] natefinch: how far back are we doing bug fixes (what versions are we still supporting)? [16:38] the bug is in 1.20 [16:39] but I don't think we're supporting that [16:48] katco: do you know how far back are we doing bug fixes (what versions are we still supporting)? [16:48] katco: I'm working on a bug reported against 1.20, but I'm pretty sure we're not still releasing 1.20 [16:49] voidspace: yeah i'm pretty sure we aren't releasing anything < 1.22. sinzui comments? [16:50] katco: we are not. also we have nothing scheduled to 1.22. only 1.24 has plans for a release [16:50] voidspace: ^ [16:50] sinzui: thanks [16:50] katco: thanks too [16:50] voidspace: o/ sorry we don't get to talk much [16:50] PS, don't merge into 1.23, it wont pass without other backports [16:50] ok [16:50] katco: yeah :-/ [16:51] katco: but o/ from across the water... [16:51] voidspace: :) how is the newbie family member doing? [16:52] katco: he's good. Keeping us busy, very demanding of attention - desparate to walk and eat but too young for either (5 months no teeth) [16:52] but very adorable of course [16:52] katco: how's yours? [16:52] aw glad to hear it :) [16:52] well she gave the family another lovely chest cold [16:52] so she's recovering, but overall doing good [16:52] he's lovely, much more sociable than Irina was - who still doesn't really like people very much :-) [16:53] started walking a few weeks ago [16:53] katco: heh [16:53] katco: ah, chaos time :-) [16:53] hah yeah [16:53] voidspace: isn't it weird how their personalities can come through at such a young age [16:53] yeah, lovely to watch personality develop [16:54] Irina is in the "why" and "what" phase - she asks about 428 times a day what a word means [16:54] which is cool [16:54] and inevitably every answer has another word she wants explained [16:54] so we end up in these long exhausting chains of explaining things [16:55] but it's great that she's so thirsty to learn [16:55] haha [16:55] yeah i bet that's neat [16:55] anxiously waiting for that stage [16:56] so far (aged four) Irina has got more and more fun as she grows [16:56] i am definitely a >= toddler person. not overly excited about babies [16:56] very excited to be able to communicate better [16:56] hehe - me too mostly [16:57] yep, it's *so* much better when you can explain things to them and they can understand [16:57] i was just thinking yesterday when she was not feeling great [16:57] we went on a big road trip round Europe - Irina was fine in the car, but you can't explain to a baby why they're in the car and how long it will be for [16:57] cherylj, nothing specifically. i want 1.25 to branch :) [16:57] she was crying and i was wishing she could tell me what was wrong [16:57] yeah, that's hard [16:57] voidspace: haha so true === mrjazzcat is now known as mrjazzcat-afk [17:55] Bug #1489087 opened: certificate verify failed [19:14] katco: bug 1489131 jeopardises our release of 1.25-alpha1 tomorrow. I think cherylj fixes something similar to this yesterday. [19:14] Bug #1489131: BootstrapSuite.TestRunTests fails on non-amd64 archs

[19:14] cherylj: ring any bells? [19:15] katco: let me take a look [19:15] cherylj: I would phrase this as have you seen anf fixed a mistake like this before? [19:16] sinzui: it looks like it's in the same vein as the blocker yesterday, but it's in a different spot. [19:16] cherylj: I wonder if someone cargo culted one of the areas you fixed before your fix merged [19:18] sinzui: I see davechen1y was in the offending file 2 days ago. [19:26] hmm, I'm puzzled why this wouldn't have been hit before... [19:26] it's not as a result of a recent change, as far as I can tell [19:27] wait, this could be due to Dave's changes yesterday [19:29] yeah, I think it is. Either way, it's an easy fix. [19:36] https://bugs.launchpad.net/juju-core/+bug/1489142 [19:36] Bug #1489142: cpu-power constraint conflicts with with instance-type when trying to launch a t2.medium [19:36] we really need help with this bug [19:37] it's currently blocking a demo we need to deliver tomorrow and this bug kind of reached out to bite us. [19:37] critical issue here for Mark's demo tomorrow at Silicon Valley OpenStack ^ [19:37] jcastro: arosales: TAL [19:37] Bug #1489131 opened: BootstrapSuite.TestRunTests fails on non-amd64 archs

[19:37] Bug #1489142 opened: cpu-power constraint conflicts with with instance-type when trying to launch a t2.medium [19:38] jcastro: is the behavior any different if you do add-machine first? [19:38] trying now [19:40] katco: no change, same result [19:40] jcastro: k, peeking around the code [19:40] http://paste.ubuntu.com/12201667/ [19:42] jcastro: what version is this? [19:42] 1.24.5 [19:44] katco: anything that just lets us deploy to a t2.medium, even if it's ugly, would do the trick [19:44] katco: even explicitly setting cpu-power=0 in the global constraints for the environment I still get no instance types in us-west-2 matching constraints "cpu-power=100 [19:44] instance-type=t2.medium" [19:45] Review request for the blocker if someone could take a look: http://reviews.vapour.ws/r/2492/ [19:49] marcoceppi: what do you get when you run juju get-constraints? [19:49] you can unset all constraings with set-constraints "" I think [19:49] constraints, even [19:52] jcastro: can you unset the constraints with juju set-constraints "" ? [19:52] he's on the phone, one sec [19:52] kk [19:53] cherylj: it's empty when I first ran it [19:53] well that's interesting [19:53] cherylj: it's now cpu-power=0 which has no effect [19:54] cherylj: it's always been empty, fwiw :) [19:54] hmm, wonder where it's coming from, then [19:54] { // General Purpose, 3rd generation. [19:54] Name: "t2.medium", [19:54] Arches: amd64, [19:54] CpuCores: 2, [19:54] Mem: 4096, [19:54] // Burstable baseline is 40% (from http://aws.amazon.com/ec2/faqs/#burst) [19:54] CpuPower: instances.CpuPower(40), [19:54] VirtType: ¶virtual, [19:54] }, [19:54] try setting it to less than 40 [19:55] mramm: you can't [19:55] ok [19:55] juju deploy cassandra --constraints="cpu-power=0 instance-type=t2.medium" -n 3 [19:55] Added charm "cs:trusty/cassandra-3" to the environment. [19:55] ERROR ambiguous constraints: "cpu-power" overlaps with "instance-type" [19:56] and if you just do --constraints="instance-type=t2.medium", that doesn't work? [19:56] cherylj: see bug 1489142 [19:56] cherylj: no, I get this error [19:56] Bug #1489142: cpu-power constraint conflicts with with instance-type when trying to launch a t2.medium [19:56] no instance types in us-west-2 matching constraints "cpu-power=100 instance-type=t2.medium" [19:56] marcoceppi: specifying both cpu-power and instance-type is the correct error [19:56] katco: cool, figured it was [19:57] marcoceppi: specifying instance-type is the mystery atm [19:57] I would have never tried if I didn't get the above error first :) [19:57] yeah hehe [19:58] and you really need t2.medium? [19:58] katco cherylj mramm http://paste.ubuntu.com/12201761/ [19:58] yes, the demo needs a t2.medium [19:58] can't be another instance type [19:58] mramm: it's the only amazon instance that matches the orangebox openstack demo of 2 cpus and 4 gb of ram [19:59] I wonder if CPU-power is specified as an environment level, and we're just combining them dumbly [19:59] environment-level constraint that is [19:59] https://github.com/juju/juju/blob/master/provider/ec2/image.go#L22 [19:59] natefinch: that's what I thought too, but we should be able to see that with get-constraints which marcoceppi says is empty [20:00] can you get a t2.medium by JUST using cpu-power=40 [20:00] cherylj: wellthere are global default constraints, that never show up, ie: cpu-power=100 cpu-cores=1 mem=1.5g, etc [20:00] mramm: trying that now [20:00] marcoceppi: mramm: yeah just going to suggest that [20:01] uh, i got this http://paste.ubuntu.com/12201785/ [20:02] ahh VPC... dreaded VPC [20:02] t2 instnances don't have this requirement though [20:02] this is an m4 isntance it tried to launch [20:02] my guess m4.large [20:03] interesting [20:03] marcoceppi: try "arch=amd64 cpu-cores=2 mem=4096 cpu-power=40" [20:03] marcoceppi: (basically just specifying the things declared by default in a t2.medium) [20:04] ericsnow: wwitzel3: natefinch: all hands [20:04] perrito666: ping ^^ [20:04] ahh, yep, one more line .... [20:04] if this doesn't work I'll spin the instances by hand and manual provider them in with ssh [20:05] katco: http://paste.ubuntu.com/12201804/ [20:05] "It’s interesting to note that Amazon is making T2 instances VPC-only. This is a mechanism to move newer workloads to VPC by default." [20:06] wtf it didn't say that on the page I was looking at [20:06] okay, so how do I get a vpc juju thingy [20:06] You must launch your T2 instances into a virtual private cloud (VPC); they are not supported on the EC2-Classic platform. [20:06] katco: what's the hangout? it isn't on my calendar [20:06]