| 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:35 |
| menn0 | master is unblocked again | 01:36 |
| sinzui | master cannot be unblcked without a bless | 01:45 |
| sinzui | PS I just forced a retest to help master get a bless. | 01:46 |
| anastasiamac | sinzui: \o/ tyvm | 01:50 |
| menn0 | sinzui: sorry | 02:14 |
| sinzui | you are forgiven menn0 | 02:14 |
| sinzui | only one job left, then I can sleep | 02:15 |
| 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> | 02:47 |
| 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:22 |
| davecheney | wow | 03:28 |
| davecheney | ./worker/... tests take > 40 minutes to run on ppc64 | 03:28 |
| axw_ | davecheney: how much is uniter? | 03:29 |
| davecheney | > 600 seconds | 03:29 |
| davecheney | timed out | 03:29 |
| axw_ | heh | 03:29 |
| 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:20 |
| mup | Bug #1488777 opened: Add a wait command <juju-core:New> <https://launchpad.net/bugs/1488777> | 06:41 |
| davechen1y | http://reviews.vapour.ws/r/2484/ | 07:43 |
| davechen1y | ping | 07:43 |
| 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:16 |
| dimitern | bogdanteleaga, https://github.com/golang/go/wiki/SliceTricks | 08:18 |
| bogdanteleaga | I guess it's a = append(a[:i], append(b, a[i:]...)...), wouldn't call it pretty tho | 08:20 |
| dimitern | voidspace, TheMue, http://reviews.vapour.ws/r/2486/ please take a look - provisioning support for spaces constraints | 08:32 |
| dimitern | bogdanteleaga, the beauty is within :D | 08:34 |
| bogdanteleaga | haha | 08:37 |
| voidspace | dimitern: looking | 08:38 |
| 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:40 |
| dimitern | voidspace, ok, so all will be sorted out soon hopefully :) | 08:42 |
| TheMue | dimitern: could you tell me why machineSubnetsAndZones() only uses includeSpaces[0]? (or do I'm looking wrong?) | 08:44 |
| 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:45 |
| TheMue | dimitern: yeah, read it. but why? simply helping me to understand it. it's a new topic for me. ;) | 08:46 |
| dimitern | TheMue, for simplicity | 08:48 |
| dimitern | TheMue, we want a *minimal* viable product :) | 08:48 |
| TheMue | dimitern: ok, sounds good :) | 08:48 |
| 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:49 |
| TheMue | dimitern: thx | 08:50 |
| TheMue | dimitern: you've got a review | 08:52 |
| dimitern | TheMue, thanks! | 08:53 |
| voidspace | dimitern: will be a couple of minutes late to standup - on the phone :-/ | 08:59 |
| dimitern | voidspace, sure | 08:59 |
| voidspace | dimitern: lost connection - rejoining | 09:07 |
| voidspace | dimitern: lost connection again - rejoining | 09:10 |
| voidspace | dimitern: struggling to rejoin apparently | 09:11 |
| voidspace | dimitern: dammit - connection lost again | 09:18 |
| 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:19 |
| 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:20 |
| voidspace | I can add it as a comment on the bug to give Ed a chance to comment | 09:21 |
| dimitern | voidspace, yes, that sounds good | 09:25 |
| voidspace | dimitern: cool | 09:25 |
| 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:26 |
| 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:28 |
| 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:29 |
| dimitern | voidspace, how can a previous default address both still exist and not be an exact match? | 09:30 |
| voidspace | dimitern: because if there isn't an exact match on scope / type we allow fallbacks | 09:31 |
| === anthonyf is now known as Guest39525 | ||
| 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:31 |
| 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:32 |
| 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:33 |
| dimitern | voidspace, also, I'd appreciate a review on my PR :) | 09:35 |
| voidspace | dimitern: ok, I've written up my suggestion on the bug and will switch to your PR now | 09:37 |
| dimitern | voidspace, cheers! | 09:38 |
| rogpeppe | trivial review anyone (no logic changes, just a data change): https://github.com/juju/juju/pull/3110 | 09:47 |
| voidspace | dimitern: exactly duplicated test setup code in api and apiserver :-/ | 09:48 |
| dimitern | voidspace, it's not quite duplicated :) | 09:48 |
| 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:49 |
| 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:52 |
| 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:53 |
| 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! | 09:57 |
| 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:01 |
| voidspace | anyway, looks ok to me - dependent on the EC2 support of course | 10:02 |
| 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:06 |
| voidspace | cool | 10:07 |
| perrito666 | morning | 10:46 |
| * 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:27 | |
| perrito666 | fwereade: you can tell your self you told you so | 11:28 |
| 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:37 |
| dimitern | TheMue, awesome! | 12:38 |
| 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:40 |
| dimitern | TheMue, this is unrelated, but I like it | 12:47 |
| dimitern | TheMue, we should bring it up on the ML for discussion | 12:47 |
| TheMue | dimitern: yep, will do so | 12:51 |
| 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 | 13:54 |
| dimitern | voidspace, hey, how goes the forward port btw? | 14:15 |
| frobware | dimitern, do you have time to HO for build/test related stuff? | 14:16 |
| dimitern | frobware, I do, just give me 10m ? | 14:19 |
| frobware | dimitern, np | 14:19 |
| 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:24 |
| 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:25 |
| 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:26 |
| sinzui | dimitern: Ci sees it everyewhere, but is ppc64el most http://reports.vapour.ws/releases/issue/55d89569749a56415476f23b | 14:27 |
| dimitern | sinzui, so if we disable it on ppc64, it should improve things for the time being? | 14:29 |
| sinzui | yes, but we still risk failure on some other arch until we fix the test | 14:30 |
| dimitern | sinzui, agreed, I'll look into it tomorrow | 14:32 |
| sinzui | :) | 14:32 |
| 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:34 |
| 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:35 |
| sinzui | dimitern: once your current PR is merges (assuming a bless) do we haver all the features in place for a release? | 14:36 |
| dimitern | sinzui, I have no others of mine | 14:38 |
| dimitern | sinzui, and I believe nothing critical remains from our stuff | 14:39 |
| sinzui | thank you dimitern | 14:39 |
| dimitern | frobware, *whew* sorry for the delay, let's get in a HO now? | 14:40 |
| frobware | dimitern, ok | 14:43 |
| ericsnow | wwitzel3: ah, glad you caught that | 14:46 |
| 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:08 |
| 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:09 |
| * 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:10 |
| 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:11 |
| * 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:12 |
| 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:13 |
| 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:14 |
| natefinch | marcoceppi: looking | 15:19 |
| marcoceppi | natefinch: thanks! | 15:24 |
| natefinch | marcoceppi: first thought is that it might be networking problems. timeouts usually mean networking | 15:27 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:54 |
| natefinch | ionutbalutoiu: I believe so. config-changed hooks get run a lot. The code in them should be written with that in mind. | 15:57 |
| voidspace | dimitern: oh yeah, meant to tell you - sorry | 16:09 |
| voidspace | dimitern: it's already on master | 16:09 |
| 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:22 |
| voidspace | natefinch: for bugfixes, which branch should we target? | 16:23 |
| voidspace | 1.24? | 16:23 |
| voidspace | natefinch: nice haircut by the way | 16:23 |
| natefinch | voidspace: thanks | 16:35 |
| natefinch | voidspace: uh... bug fixes for what? | 16:35 |
| 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:38 |
| voidspace | but I don't think we're supporting that | 16:39 |
| 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:48 |
| katco | voidspace: yeah i'm pretty sure we aren't releasing anything < 1.22. sinzui comments? | 16:49 |
| 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:50 |
| voidspace | katco: but o/ from across the water... | 16:51 |
| katco | voidspace: :) how is the newbie family member doing? | 16:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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 | 16:57 |
| === mrjazzcat is now known as mrjazzcat-afk | ||
| mup | Bug #1489087 opened: certificate verify failed <juju-core:New> <https://launchpad.net/bugs/1489087> | 17:55 |
| 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:14 |
| 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:15 |
| 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:16 |
| cherylj | sinzui: I see davechen1y was in the offending file 2 days ago. | 19:18 |
| 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:26 |
| cherylj | wait, this could be due to Dave's changes yesterday | 19:27 |
| cherylj | yeah, I think it is. Either way, it's an easy fix. | 19:29 |
| 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:36 |
| 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:37 |
| katco | jcastro: is the behavior any different if you do add-machine first? | 19:38 |
| jcastro | trying now | 19:38 |
| jcastro | katco: no change, same result | 19:40 |
| katco | jcastro: k, peeking around the code | 19:40 |
| marcoceppi | http://paste.ubuntu.com/12201667/ | 19:40 |
| katco | jcastro: what version is this? | 19:42 |
| jcastro | 1.24.5 | 19:42 |
| 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:44 |
| cherylj | Review request for the blocker if someone could take a look: http://reviews.vapour.ws/r/2492/ | 19:45 |
| 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:49 |
| 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:52 |
| 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:53 |
| 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: ¶virtual, | 19:54 |
| mramm | }, | 19:54 |
| mramm | try setting it to less than 40 | 19:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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 | 19:59 |
| 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:00 |
| marcoceppi | uh, i got this http://paste.ubuntu.com/12201785/ | 20:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| katco | marcoceppi: jcastro: here's the algo. for performing the selection: https://github.com/juju/juju/blob/master/environs/instances/instancetype.go#L95 | 20:16 |
| marcoceppi | mramm katco so with a default vcp, will all my instances just luanch in it? | 20:19 |
| 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:20 |
| mramm | katco: marcoceppi: I believe that is correct | 20:21 |
| 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:25 |
| 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:27 |
| marcoceppi | I need this ami-afd5c09f for hvm apparently | 20:28 |
| natefinch | marcoceppi: http://cdn.meme.am/instances/55580985.jpg | 20:29 |
| jcastro | we're going to launch them by hand and then just add-machine via ssh | 20:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| natefinch | so, instance-type works. just not with t2.... so probably it's the VPC thing causing an error that we interpret incorrectly. | 20:38 |
| jcastro | yeah | 20:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:45 |
| 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:46 |
| natefinch | katco: this is why we have reviews :) (and also tests, but I understand not writing the test in a crunch) | 20:47 |
| katco | natefinch: recheck | 20:48 |
| natefinch | katco: got a typo in the comment there.... think you were typing in the wrong window | 20:48 |
| katco | natefinch: again | 20:49 |
| natefinch | katco: ship it! | 20:50 |
| 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:51 |
| 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:52 |
| natefinch | jcastro: manual provider should do well enough | 20:53 |
| natefinch | jcastro: at least for last minute demo purpsoes | 20:53 |
| jcastro | indeed | 20:53 |
| 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:54 |
| 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> | 20:55 |
| === natefinch is now known as natefinch-afk | ||
| katco | wallyworld: hey can you TAL at http://reviews.vapour.ws/r/2493/diff/# and see if it seems sane? | 21:27 |
| wallyworld | sure | 21:37 |
| davechen1y | cherylj: thanks for the fix | 22:57 |
| 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 | 22:58 |
| wallyworld | anastasiamac: standup? | 23:18 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
