[01:35] <menn0> 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] <menn0> bug 1488581
[01:35] <mup> Bug #1488581: TestFindToolsExactInStorage fails for some archs <blocker> <ci> <i386> <ppc64el> <regression> <storage> <unit-tests> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1488581>
[01:35] <anastasiamac> menn0: cherylj: tyvm!!
[01:36] <menn0> master is unblocked again
[01:45] <sinzui> master cannot be unblcked without a bless
[01:46] <sinzui> PS I just forced a retest to help master get a bless.
[01:50] <anastasiamac> sinzui: \o/ tyvm
[02:14] <menn0> sinzui: sorry
[02:14] <sinzui> you are forgiven menn0
[02:15] <sinzui> only one job left, then I can sleep
[02:47] <mup> Bug #1488581 changed: TestFindToolsExactInStorage fails for some archs <blocker> <ci> <i386> <ppc64el> <regression> <storage> <unit-tests> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1488581>
[03:22] <axw_> wallyworld: the `storage: add volume status to "juju storage volume list"` card *was* done
[03:22] <axw_> just checked, it's in master
[03:22] <axw_> moving card from review to previous
[03:22] <wallyworld> axw_: awesome, wanna add a sentence to the release notes?
[03:22] <axw_> wallyworld: will do
[03:22] <wallyworld> ty
[03:28] <davecheney> wow
[03:28] <davecheney> ./worker/... tests take > 40 minutes to run on ppc64
[03:29] <axw_> davecheney: how much is uniter?
[03:29] <davecheney> > 600 seconds
[03:29] <davecheney> timed out
[03:29] <axw_> heh
[06:20] <davecheney> http://reviews.vapour.ws/r/2483/
[06:20] <davecheney> this fixes the patch that cherylj landed earlier
[06:20] <davecheney> not that her's was wrong
[06:20] <davecheney> this is just the proper fix
[06:41] <mup> Bug #1488777 opened: Add a wait command <juju-core:New> <https://launchpad.net/bugs/1488777>
[07:43] <davechen1y> http://reviews.vapour.ws/r/2484/
[07:43] <davechen1y> ping
[08:16] <bogdanteleaga> is there a pretty way in golang to insert a slice of strings in the middle of another slice?
[08:16] <bogdanteleaga> davechen1y ^^
[08:18] <dimitern> bogdanteleaga, https://github.com/golang/go/wiki/SliceTricks
[08:20] <bogdanteleaga> I guess it's a = append(a[:i], append(b, a[i:]...)...), wouldn't call it pretty tho
[08:32] <dimitern> voidspace, TheMue, http://reviews.vapour.ws/r/2486/ please take a look - provisioning support for spaces constraints
[08:34] <dimitern> bogdanteleaga, the beauty is within :D
[08:37] <bogdanteleaga> haha
[08:38] <voidspace> dimitern: looking
[08:40] <voidspace> hmmm... coffee first
[08:40] <voidspace> dimitern: the travel provider booked me tickets from London to Northampton, and then on the friday back from Northampton to London...
[08:40] <voidspace> oops
[08:40] <voidspace> dimitern: they're buying me new tickets now (for the sprint)
[08:42] <dimitern> voidspace, ok, so all will be sorted out soon hopefully :)
[08:44] <TheMue> dimitern: could you tell me why machineSubnetsAndZones()  only uses includeSpaces[0]? (or do I'm looking wrong?)
[08:45] <dimitern> TheMue, there is a comment about it
[08:45] <dimitern> TheMue, for the MVP work we only use the first positive space and ignore the rest
[08:46] <TheMue> dimitern: yeah, read it. but why? simply helping me to understand it. it's a new topic for me. ;)
[08:48] <dimitern> TheMue, for simplicity
[08:48] <dimitern> TheMue, we want a *minimal* viable product :)
[08:48] <TheMue> dimitern: ok, sounds good :)
[08:49] <dimitern> 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] <TheMue> dimitern: thx
[08:52] <TheMue> dimitern: you've got a review
[08:53] <dimitern> TheMue, thanks!
[08:59] <voidspace> dimitern: will be a couple of minutes late to standup - on the phone :-/
[08:59] <dimitern> voidspace, sure
[09:07] <voidspace> dimitern: lost connection - rejoining
[09:10] <voidspace> dimitern: lost connection again - rejoining
[09:11] <voidspace> dimitern: struggling to rejoin apparently
[09:18] <voidspace> dimitern: dammit - connection lost again
[09:19] <voidspace> 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] <voidspace> 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] <voidspace> dimitern: so we always return the same one until / unless a better match is found - and then we always return that one
[09:20] <voidspace> dimitern: so we *can* change address - but only if we were using a fallback scope or type
[09:20] <voidspace> dimitern: does that sound like a reasonable algorithm?
[09:21] <voidspace> I can add it as a comment on the bug to give Ed a chance to comment
[09:25] <dimitern> voidspace, yes, that sounds good
[09:25] <voidspace> dimitern: cool
[09:26] <dimitern> 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] <voidspace> dimitern: where "per scope" is private / public
[09:28] <dimitern> 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] <voidspace> dimitern: but yes
[09:28] <voidspace> dimitern: yes
[09:28] <voidspace> dimitern: the algorithm looks like this
[09:28] <voidspace> dimitern: first time requested use the first "match" using the current algorithm
[09:28] <voidspace> dimitern: subsequent requests, check if the stored default is an exact match - if it is *always* use it
[09:29] <voidspace> dimitern: if the default isn't an exact match check if an exact match is now available
[09:29] <voidspace> dimitern: if not, use the current default (so we remain stable)
[09:29] <voidspace> dimitern: if an exact match is available, store that as the default and use that
[09:29] <voidspace> dimitern: subsequent requests will now always see the new default
[09:30] <dimitern> voidspace, how can a previous default address both still exist and not be an exact match?
[09:31] <voidspace> dimitern: because if there isn't an exact match on scope / type we allow fallbacks
[09:31] <voidspace> dimitern: e.g. if preferipv6 is on we can return an ipv4 address if an ipv6 one isn't available
[09:31] <dimitern> voidspace, ah, because the previous default might have been a fallback
[09:32] <voidspace> dimitern: so the first part is "if an exact match isn't available still store the fallback as default"
[09:32] <voidspace> dimitern: to ensure we always return the same one unless / until an exact match is available
[09:33] <dimitern> 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] <dimitern> voidspace, also, I'd appreciate a review on my PR :)
[09:37] <voidspace> dimitern: ok, I've written up my suggestion on the bug and will switch to your PR now
[09:38] <dimitern> voidspace, cheers!
[09:47] <rogpeppe> trivial review anyone (no logic changes, just a data change): https://github.com/juju/juju/pull/3110
[09:48] <voidspace> dimitern: exactly duplicated test setup code in api and apiserver :-/
[09:48] <dimitern> voidspace, it's not quite duplicated :)
[09:49] <dimitern> voidspace, but fair point - it can be put in a common place
[09:49] <dimitern> voidspace, state/testing ?
[09:49] <voidspace> dimitern: sounds good.
[09:52] <voidspace> dimitern: your call
[09:52] <voidspace> dimitern: for *two* use cases it's barely worth it
[09:52] <voidspace> dimitern: for three it would definitely be worth it
[09:53] <voidspace> dimitern: I won't add it as an issue on the PR, just noting it
[09:53] <dimitern> voidspace, the duplication was bugging me as well, but wanted to make it work first, then polish
[09:53] <dimitern> voidspace, ok
[09:57] <voidspace> s.checkStartInstanceCustom(c, m, "pork", s.defaultConstraints, nil, nil, nil, nil, false, nil, true)
[09:57] <voidspace> nil, nil, nil, nil, false, nil, true
[09:57] <voidspace> self documenting code be damned!
[10:01] <voidspace> dimitern: ah, so this PR only adds support into the dummy provider
[10:01] <voidspace> dimitern: EC2 will be a follow up
[10:01] <voidspace> I was looking for where the new mapping was actually used!
[10:02] <voidspace> anyway, looks ok to me - dependent on the EC2 support of course
[10:06] <dimitern> voidspace, yeah, it had to include the dummy provider support
[10:06] <dimitern> voidspace, thanks, will update with the suggestions and set it to land
[10:07] <voidspace> cool
[10:46] <perrito666> 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] <perrito666> fwereade: you can tell your self you told you so
[12:37] <TheMue> 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] <dimitern> TheMue, awesome!
[12:40] <TheMue> 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] <dimitern> TheMue, this is unrelated, but I like it
[12:47] <dimitern> TheMue, we should bring it up on the ML for discussion
[12:51] <TheMue> dimitern: yep, will do so
[13:54] <sinzui> 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] <natefinch> 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] <ericsnow> natefinch: cool
[14:15] <dimitern> voidspace, hey, how goes the forward port btw?
[14:16] <frobware> dimitern, do you have time to HO for build/test related stuff?
[14:19] <dimitern> frobware, I do, just give me 10m ?
[14:19] <frobware> dimitern, np
[14:24] <sinzui> 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] <sinzui> dimitern: also Lp wont let me update bug 1488576 at the moment. It is a rising problem in the test suite
[14:25] <mup> Bug #1488576: TestAddresserWorkerStopsWhenAddressDeallocationNotSupported fails on pp64el <ci> <intermittent-failure> <ppc64el> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1488576>
[14:26] <dimitern> sinzui, I have one PR with I'll set to land in 2 minutes
[14:26] <dimitern> sinzui, re that bug - I vote to skip it on ppc64
[14:27] <sinzui> dimitern: Ci sees it everyewhere, but is ppc64el most http://reports.vapour.ws/releases/issue/55d89569749a56415476f23b
[14:29] <dimitern> sinzui, so if we disable it on ppc64, it should improve things for the time being?
[14:30] <sinzui> yes, but we still risk failure on some other arch until we fix the test
[14:32] <dimitern> sinzui, agreed, I'll look into it tomorrow
[14:32] <sinzui> :)
[14:34] <dimitern> sinzui, actually, I'm seeing failures even locally
[14:34] <dimitern> sinzui, I'll disable it entirely then
[14:34] <wwitzel3> ericsnow: found my bug :)
[14:34] <dimitern> sinzui, then tomorrow will dig into it some more
[14:35] <sinzui> 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] <wwitzel3> 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] <sinzui> dimitern: once your current PR is merges (assuming a bless) do we haver all the features in place for a release?
[14:38] <dimitern> sinzui, I have no others of mine
[14:39] <dimitern> sinzui, and I believe nothing critical remains from our stuff
[14:39] <sinzui> thank you dimitern
[14:40] <dimitern> frobware, *whew* sorry for the delay, let's get in a HO now?
[14:43] <frobware> dimitern, ok
[14:46] <ericsnow> wwitzel3: ah, glad you caught that
[15:08] <marcoceppi> 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] <marcoceppi> hey core guys and gals*
[15:08] <marcoceppi> hey core ppl*
[15:09] <mgz> pc fail
[15:09] <marcoceppi> actually trying to break old habbits of calling everyone guys
[15:09] <mgz> er... as in 'politial correctness'
[15:10]  * marcoceppi is not sloth
[15:10] <mgz> it's good to try :)
[15:10] <mgz> I basically think of guys as gender neutral these days, it's how it seems to be used
[15:11] <mgz> I've seen women using it to address a mixed group, but I guess not a all-female group
[15:11] <cherylj> 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] <natefinch> y'all
[15:12] <natefinch> or all-y'all
[15:12] <katco> natefinch: personally hate that colloquialism
[15:12] <natefinch> katco: lol me too
[15:12] <cherylj> I don't think I've ever used y'all un-ironically
[15:13] <cherylj> and I'm from texas, y'all!
[15:13] <katco> lol
[15:13] <marcoceppi> 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] <mgz> eheheh
[15:13] <natefinch> cherylj: me either, but I'm a Yankee
[15:13] <mgz> I use peeps ironically, except sometimes I forget the irony
[15:13] <natefinch> heh
[15:13] <marcoceppi> everything I say is ironic
[15:13] <natefinch> even that!
[15:14] <marcoceppi> 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] <natefinch> marcoceppi: looking
[15:24] <marcoceppi> natefinch: thanks!
[15:27] <natefinch> marcoceppi: first thought is that it might be networking problems.  timeouts usually mean networking
[15:50] <sinzui> 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] <cherylj> sinzui: that works for me, but I don't know if there are other merges we're waiting on.
[15:51] <cherylj> cmars, katco, are there things you're wanting in  1.25-alpha1?
[15:51] <sinzui> ^ katco are you really hear to call the cut of 1.25-alpha1?
[15:51] <sinzui> here
[15:52] <mup> Bug #1489053 opened: rabbitmq-server charm fails on cluster-relation-changed when using openstack provider <juju-core:New> <https://launchpad.net/bugs/1489053>
[15:52] <katco> sinzui: i'm here
[15:52] <katco> cherylj: sinzui: sorry been out sick... moonstone didn't have anything for 1.25
[15:54] <ionutbalutoiu> 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] <natefinch> ionutbalutoiu: I believe so.  config-changed hooks get run a lot.  The code in them should be written with that in mind.
[16:09] <voidspace> dimitern: oh yeah, meant to tell you - sorry
[16:09] <voidspace> dimitern: it's already on master
[16:22] <mup> Bug #1489053 changed: rabbitmq-server charm fails on cluster-relation-changed when using openstack provider <rabbitmq-server (Juju Charms Collection):New> <https://launchpad.net/bugs/1489053>
[16:23] <voidspace> natefinch: for bugfixes, which branch should we target?
[16:23] <voidspace> 1.24?
[16:23] <voidspace> natefinch: nice haircut by the way
[16:35] <natefinch> voidspace: thanks
[16:35] <natefinch> voidspace: uh... bug fixes for what?
[16:38] <voidspace> natefinch: I am working on a juju-core bug
[16:38] <voidspace> natefinch: how far back are we doing bug fixes (what versions are we still supporting)?
[16:38] <voidspace> the bug is in 1.20
[16:39] <voidspace> but I don't think we're supporting that
[16:48] <voidspace> katco:  do you know how far back are we doing bug fixes (what versions are we still supporting)?
[16:48] <voidspace> 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] <katco> voidspace: yeah i'm pretty sure we aren't releasing anything < 1.22. sinzui comments?
[16:50] <sinzui> katco: we are not. also we have nothing scheduled to 1.22. only 1.24 has plans for a release
[16:50] <sinzui> voidspace: ^
[16:50] <voidspace> sinzui: thanks
[16:50] <voidspace> katco: thanks too
[16:50] <katco> voidspace: o/ sorry we don't get to talk much
[16:50] <sinzui> PS, don't merge into 1.23, it wont pass without other backports
[16:50] <voidspace> ok
[16:50] <voidspace> katco: yeah :-/
[16:51] <voidspace> katco: but o/ from across the water...
[16:51] <katco> voidspace: :) how is the newbie family member doing?
[16:52] <voidspace> 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] <voidspace> but very adorable of course
[16:52] <voidspace> katco: how's yours?
[16:52] <katco> aw glad to hear it :)
[16:52] <katco> well she gave the family another lovely chest cold
[16:52] <katco> so she's recovering, but overall doing good
[16:52] <voidspace> he's lovely, much more sociable than Irina was - who still doesn't really like people very much :-)
[16:53] <katco> started walking a few weeks ago
[16:53] <voidspace> katco: heh
[16:53] <voidspace> katco: ah, chaos time :-)
[16:53] <katco> hah yeah
[16:53] <katco> voidspace: isn't it weird how their personalities can come through at such a young age
[16:53] <voidspace> yeah, lovely to watch personality develop
[16:54] <voidspace> Irina is in the "why" and "what" phase - she asks about 428 times a day what a word means
[16:54] <voidspace> which is cool
[16:54] <voidspace> and inevitably every answer has another word she wants explained
[16:54] <voidspace> so we end up in these long exhausting chains of explaining things
[16:55] <voidspace> but it's great that she's so thirsty to learn
[16:55] <katco> haha
[16:55] <katco> yeah i bet that's neat
[16:55] <katco> anxiously waiting for that stage
[16:56] <voidspace> so far (aged four) Irina has got more and more fun as she grows
[16:56] <katco> i am definitely a >= toddler person. not overly excited about babies
[16:56] <katco> very excited to be able to communicate better
[16:56] <voidspace> hehe - me too mostly
[16:57] <voidspace> yep, it's *so* much better when you can explain things to them and they can understand
[16:57] <katco> i was just thinking yesterday when she was not feeling great
[16:57] <voidspace> 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] <cmars> cherylj, nothing specifically. i want 1.25 to branch :)
[16:57] <katco> she was crying and i was wishing she could tell me what was wrong
[16:57] <voidspace> yeah, that's hard
[16:57] <katco> voidspace: haha so true
[17:55] <mup> Bug #1489087 opened: certificate verify failed <juju-core:New> <https://launchpad.net/bugs/1489087>
[19:14] <sinzui> katco: bug 1489131 jeopardises our release of 1.25-alpha1 tomorrow. I think cherylj fixes something similar to this yesterday.
[19:14] <mup> Bug #1489131: BootstrapSuite.TestRunTests fails on non-amd64 archs <blocker> <ci> <ppc64el> <regression> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1489131>
[19:14] <katco> cherylj: ring any bells?
[19:15] <cherylj> katco: let me take a look
[19:15] <sinzui> cherylj: I would phrase this as have you seen anf fixed a mistake like this before?
[19:16] <cherylj> sinzui: it looks like it's in the same vein as the blocker yesterday, but it's in a different spot.
[19:16] <sinzui> cherylj: I wonder if someone cargo culted one of the areas you fixed before your fix merged
[19:18] <cherylj> sinzui: I see davechen1y was in the offending file 2 days ago.
[19:26] <cherylj> hmm, I'm puzzled why this wouldn't have been hit before...
[19:26] <cherylj> it's not as a result of a recent change, as far as I can tell
[19:27] <cherylj> wait, this could be due to Dave's changes yesterday
[19:29] <cherylj> yeah, I think it is.    Either way, it's an easy fix.
[19:36] <jcastro> https://bugs.launchpad.net/juju-core/+bug/1489142
[19:36] <mup> Bug #1489142: cpu-power constraint conflicts with with instance-type when trying to launch a t2.medium <juju-core:New> <https://launchpad.net/bugs/1489142>
[19:36] <jcastro> we really need help with this bug
[19:37] <jcastro> it's currently blocking a demo we need to deliver tomorrow and this bug kind of reached out to bite us.
[19:37] <arosales> critical issue here for Mark's demo tomorrow at Silicon Valley OpenStack ^
[19:37] <katco> jcastro: arosales: TAL
[19:37] <mup> Bug #1489131 opened: BootstrapSuite.TestRunTests fails on non-amd64 archs <blocker> <ci> <ppc64el> <regression> <test-failure> <unit-tests> <juju-core:In Progress by cherylj> <https://launchpad.net/bugs/1489131>
[19:37] <mup> Bug #1489142 opened: cpu-power constraint conflicts with with instance-type when trying to launch a t2.medium <juju-core:New> <https://launchpad.net/bugs/1489142>
[19:38] <katco> jcastro: is the behavior any different if you do add-machine first?
[19:38] <jcastro> trying now
[19:40] <jcastro> katco: no change, same result
[19:40] <katco> jcastro: k, peeking around the code
[19:40] <marcoceppi> http://paste.ubuntu.com/12201667/
[19:42] <katco> jcastro: what version is this?
[19:42] <jcastro> 1.24.5
[19:44] <jcastro> katco: anything that just lets us deploy to a t2.medium, even if it's ugly, would do the trick
[19:44] <marcoceppi> 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] <marcoceppi>       instance-type=t2.medium"
[19:45] <cherylj> Review request for the blocker if someone could take a look: http://reviews.vapour.ws/r/2492/
[19:49] <cherylj> marcoceppi: what do you get when you run juju get-constraints?
[19:49] <cherylj> you can unset all constraings with set-constraints "" I think
[19:49] <cherylj> constraints, even
[19:52] <cherylj> jcastro: can you unset the constraints with juju set-constraints "" ?
[19:52] <jcastro> he's on the phone, one sec
[19:52] <cherylj> kk
[19:53] <marcoceppi> cherylj: it's empty when I first ran it
[19:53] <cherylj> well that's interesting
[19:53] <marcoceppi> cherylj: it's now cpu-power=0 which has no effect
[19:54] <marcoceppi> cherylj: it's always been empty, fwiw :)
[19:54] <cherylj> hmm, wonder where it's coming from, then
[19:54] <mramm> { // General Purpose, 3rd generation.
[19:54] <mramm> 		Name:     "t2.medium",
[19:54] <mramm> 		Arches:   amd64,
[19:54] <mramm> 		CpuCores: 2,
[19:54] <mramm> 		Mem:      4096,
[19:54] <mramm> 		// Burstable baseline is 40% (from http://aws.amazon.com/ec2/faqs/#burst)
[19:54] <mramm> 		CpuPower: instances.CpuPower(40),
[19:54] <mramm> 		VirtType: &paravirtual,
[19:54] <mramm> 	},
[19:54] <mramm> try setting it to less than 40
[19:55] <marcoceppi> mramm: you can't
[19:55] <mramm> ok
[19:55] <marcoceppi> juju deploy cassandra --constraints="cpu-power=0 instance-type=t2.medium" -n 3
[19:55] <marcoceppi> Added charm "cs:trusty/cassandra-3" to the environment.
[19:55] <marcoceppi> ERROR ambiguous constraints: "cpu-power" overlaps with "instance-type"
[19:56] <cherylj> and if you just do --constraints="instance-type=t2.medium", that doesn't work?
[19:56] <katco> cherylj: see bug 1489142
[19:56] <marcoceppi> cherylj: no, I get this error
[19:56] <mup> Bug #1489142: cpu-power constraint conflicts with with instance-type when trying to launch a t2.medium <juju-core:New> <https://launchpad.net/bugs/1489142>
[19:56] <marcoceppi> no instance types in us-west-2 matching constraints "cpu-power=100 instance-type=t2.medium"
[19:56] <katco> marcoceppi: specifying both cpu-power and instance-type is the correct error
[19:56] <marcoceppi> katco: cool, figured it was
[19:57] <katco> marcoceppi: specifying instance-type is the mystery atm
[19:57] <marcoceppi> I would have never tried if I didn't get the above error first :)
[19:57] <katco> yeah hehe
[19:58] <mramm> and you really need t2.medium?
[19:58] <marcoceppi> katco cherylj mramm http://paste.ubuntu.com/12201761/
[19:58] <jcastro> yes, the demo needs a t2.medium
[19:58] <jcastro> can't be another instance type
[19:58] <marcoceppi> mramm: it's the only amazon instance that matches the orangebox openstack demo of 2 cpus and 4 gb of ram
[19:59] <natefinch> I wonder if CPU-power is specified as an environment level, and we're just combining them dumbly
[19:59] <natefinch> environment-level constraint that is
[19:59] <katco> https://github.com/juju/juju/blob/master/provider/ec2/image.go#L22
[19:59] <cherylj> 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] <mramm> can you get a t2.medium by JUST using cpu-power=40
[20:00] <marcoceppi> cherylj: wellthere are global default constraints, that never show up, ie: cpu-power=100 cpu-cores=1 mem=1.5g, etc
[20:00] <marcoceppi> mramm: trying that now
[20:00] <katco> marcoceppi: mramm: yeah just going to suggest that
[20:01] <marcoceppi> uh, i got this http://paste.ubuntu.com/12201785/
[20:02] <mramm> ahh VPC... dreaded VPC
[20:02] <marcoceppi> t2 instnances don't have this requirement though
[20:02] <marcoceppi> this is an m4 isntance it tried to launch
[20:02] <marcoceppi> my guess m4.large
[20:03] <mramm> interesting
[20:03] <katco> marcoceppi: try "arch=amd64 cpu-cores=2 mem=4096 cpu-power=40"
[20:03] <katco> marcoceppi: (basically just specifying the things declared by default in a t2.medium)
[20:04] <katco> ericsnow: wwitzel3: natefinch: all hands
[20:04] <katco> perrito666: ping ^^
[20:04] <wwitzel3> ahh, yep, one more line ....
[20:04] <marcoceppi> if this doesn't work I'll spin the instances by hand and manual provider them in with ssh
[20:05] <marcoceppi> katco: http://paste.ubuntu.com/12201804/
[20:05] <mramm> "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] <marcoceppi> wtf it didn't say that on the page I was looking at
[20:06] <marcoceppi> okay, so how do I get a vpc juju thingy
[20:06] <mramm> You must launch your T2 instances into a virtual private cloud (VPC); they are not supported on the EC2-Classic platform.
[20:06] <wwitzel3> katco: what's the hangout? it isn't on my calendar
[20:06] <mramm> directly from the amazon docs
[20:06] <marcoceppi> foadthx amazon
[20:07] <katco> wwitzel3: no hangout atm
[20:07] <mramm> http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-vpc.html#vpc-only-instance-types
[20:07] <natefinch> katco: there's nothing in my calendar... what all hands?
[20:07] <katco> natefinch: wwitzel3: the discussion happening in this chat right now
[20:08] <natefinch> katco: oh, sorry, misunderstood.
[20:08] <marcoceppi> okay, so we have the instance, it's just I need a vpc now
[20:08] <katco> natefinch: wwitzel3: try and troubleshoot the first attempt in bug 1489142
[20:08] <mup> Bug #1489142: cpu-power constraint conflicts with with instance-type when trying to launch a t2.medium <constraints> <juju-core:New> <https://launchpad.net/bugs/1489142>
[20:08] <marcoceppi> and juju+vpc =...?
[20:08] <marcoceppi> I'm guessing good to go no issues at all fire away, but I'll wait
[20:10] <mramm> marcoceppi: do you have an account with default VPC?
[20:10] <mramm> that is the easiest path forward
[20:10] <mramm> IIRC
[20:10] <marcoceppi> I don't think so? my account was created like 4 years ago
[20:10] <mramm> yea, you'd need a newer account to use
[20:10] <marcoceppi> I do have a new account though
[20:10] <marcoceppi> that I have access to
[20:11] <mramm> I'm not sure how much of VPC support has actually landed in 1.24
[20:11] <natefinch> at best, we need to handle this case better.  Saying there's a conflict is a huge red herring
[20:11] <jcastro> yeah, let's sort that after we unblock marco
[20:12] <katco> natefinch: focus on the 1st use-case... the instance-type constraint doesn't seem to be working
[20:12] <mramm> natefinch: agreed there is lots here to fix
[20:13] <marcoceppi> Going to see if this new account has default vpc, in which case I can use the constraints katco gave to get unblocked
[20:13] <mramm> marcoceppi: cool
[20:16] <katco> marcoceppi: jcastro: here's the algo. for performing the selection: https://github.com/juju/juju/blob/master/environs/instances/instancetype.go#L95
[20:19] <marcoceppi> mramm katco so with a default vcp, will all my instances just luanch in it?
[20:20] <katco> marcoceppi: i haven't looked at it recently, but i think i remember reading that
[20:20] <marcoceppi> katco: seems so, bootstrap node seems to be in it
[20:21] <mramm> katco: marcoceppi: I believe that is correct
[20:25] <natefinch> didn't we used to display instance type in juju status?
[20:25] <marcoceppi> for the love of
[20:25] <marcoceppi> ugh
[20:25] <marcoceppi> 'cannot run instances: Virtualization type ''hvm'' is required
[20:25] <marcoceppi>       for instances of type ''t2.medium''. Ensure that you are using an AMI with virtualization
[20:25] <marcoceppi>       type ''hvm''. For more information, see http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/virtualization_types.html
[20:25] <marcoceppi>       (InvalidParameterCombination)'
[20:25] <marcoceppi> looks like I'm just not going to win today
[20:27] <marcoceppi> can I give juju an AMI?
[20:27] <marcoceppi> I know the answer is "no", but like, can I actually do it?
[20:27] <natefinch> marcoceppi: lol
[20:28] <marcoceppi> I need this ami-afd5c09f for hvm apparently
[20:29] <natefinch> marcoceppi: http://cdn.meme.am/instances/55580985.jpg
[20:30] <jcastro> we're going to launch them by hand and then just add-machine via ssh
[20:31] <natefinch> can you not just use a different machine size?
[20:31] <natefinch> like... bigger?
[20:31] <jcastro> no
[20:31] <jcastro> the demo requires a t2.medium
[20:32] <arosales> natefinch, we need to have a specific instance size for benchmark comparison
[20:32] <bogdanteleaga> marcoceppi: yes, you could give juju a ami to use, but you need to modify some code in core
[20:33] <arosales> bogdanteleaga, modifying code in core is a no-op for a demo tomorrow
[20:33] <bogdanteleaga> amazon only accepts image metadata that's signed
[20:33] <bogdanteleaga> that would be the problem here
[20:33] <bogdanteleaga> if you could get that, it would also work
[20:38] <natefinch> so, instance-type works. just not with t2.... so probably it's the VPC thing causing an error that we interpret incorrectly.
[20:39] <jcastro> yeah
[20:40] <katco> natefinch: wondering if instance-type is specified, should we even be setting a default cpu power? isn't that implied by instance-type?
[20:40] <jcastro> when you do it with a new account it works because amazon defaults to vpc for users newer than dec 2013
[20:40] <marcoceppi> katco: I say no, I the user supplied an instance-type, it should be the only thing that matters
[20:40] <jcastro> once you get past that though it's trying to use the pv image instead of the hvm image
[20:40] <natefinch> katco: yeah, instance-type is supposed to override everything
[20:41] <natefinch> katco: my guess is that the code that adds CPU-Power is coming later in the call stack and appending it, without considering if instance-type is set
[20:41] <natefinch> katco: although I don't think it's actually hurting us
[20:41] <katco> natefinch: pushing patch now that addresses that
[20:42] <natefinch> (aside from being confusing)
[20:42] <bogdanteleaga> got a questions about constraints since we're on the subject: is there a place to define default constraints/provider?
[20:43] <bogdanteleaga> I found that at least on aws windows machines need 35GB
[20:43] <katco> natefinch: well, i'm wondering if we didn't set cpu power to a default if the search algo could find a match
[20:43] <natefinch> bogdanteleaga: any constraints set when you bootstrap become environment-wide constraints
[20:43] <sinzui> katco: natefinch : do either of you have a minute to review cherylj's http://reviews.vapour.ws/r/2492/
[20:43] <bogdanteleaga> natefinch, yes but ideally we'd have this the default for windows instances
[20:43] <katco> sinzui: trying to resolve something blocking a demo tomorrow
[20:43] <natefinch> katco: my guess is that amazon is returning "no instances" because you don't have the default VPC, and we're just assuming it's because of the constraints mentioned
[20:45] <natefinch> katco: but certainly we shouldn't be adding the cpu-power when instance-type is set
[20:45] <natefinch> katco: so that's a fix to make regardless
[20:45] <katco> http://reviews.vapour.ws/r/2493/
[20:45] <natefinch> looking
[20:45] <natefinch> katco: logically backwards... should only be if instancetype *is* nil
[20:46] <katco> natefinch: doh... damn sick head
[20:46] <Makyo> Having some problems with panics on CI - anyone else encountered similar? http://juju-ci.vapour.ws:8080/job/github-merge-juju/4494/console
[20:47] <natefinch> katco: this is why we have reviews :)  (and also tests, but I understand not writing the test in a crunch)
[20:48] <katco> natefinch: recheck
[20:48] <natefinch> katco: got a typo in the comment there.... think you were typing in the wrong window
[20:49] <katco> natefinch: again
[20:50] <natefinch> katco: ship it!
[20:51] <katco> marcoceppi: i don't suppose a 1.24.6 beta would help at all?
[20:51] <jcastro> we're past the vpc problem for now
[20:51] <jcastro> just wrestling with the hhvm issue now
[20:51] <katco> jcastro: k
[20:52] <jcastro> t2.medium wants an ami that is built for hhvm, but juju is handing it normal pv ami's
[20:52] <katco> natefinch: i'm going to wait to merge this until ian weighs in as well. it looks like he touched a lot of the constraints code
[20:52] <jcastro> so .. the current plan is he just launched the instances by hand in the aws gui
[20:52] <jcastro> and then is manually adding the machines via ssh
[20:52] <jcastro> and then deploying cassandra onto that
[20:52] <marcoceppi> wwitzel3: http://paste.ubuntu.com/12202091/
[20:53] <natefinch> jcastro: manual provider should do well enough
[20:53] <natefinch> jcastro: at least for last minute demo purpsoes
[20:53] <jcastro> indeed
[20:54] <sinzui> Makyo: the juju unittests are poorly isolated and timed. We often see many attempts needed to merge. Because of the poor isolation, it is possible a test change you your branch unhinged the  dblogSuite.TearDownTest and dblogSuite.TestUnitAgentLogsGoToDBWithJES tests :(
[20:55] <Makyo> sinzui: ack, thanks.  I'll do a bit more digging around what changed.
[20:55] <marcoceppi> wwitzel3: https://bugs.launchpad.net/juju-core/+bug/1478156
[20:55] <mup> Bug #1478156: tabular format does not give enough details about machine provisioning errors <charmers> <juju-core:Triaged> <https://launchpad.net/bugs/1478156>
[21:27] <katco> wallyworld: hey can you TAL at http://reviews.vapour.ws/r/2493/diff/# and see if it seems sane?
[21:37] <wallyworld> sure
[22:57] <davechen1y> cherylj: thanks for the fix
[22:58] <davechen1y> fyi, i am testing these, not just comitting them blidly
[22:58] <davechen1y> on ppc64
[22:58] <davechen1y> but my ppc64 machine is so slow I cannot run all the tests
[22:58] <davechen1y> so I have to work only in the areas I think are affected
[22:58] <davechen1y> sorry i missed this one
[23:18] <wallyworld> anastasiamac: standup?