| mwhudson | davechen1y: could the shootout awfulness be caused by softfloat? | 01:13 |
|---|---|---|
| mwhudson | i.e. minux's vfp detection failing for whatever reason | 01:13 |
| davechen1y | i don't think so | 01:16 |
| davechen1y | the same command takes ~ 1.47 when run directly | 01:16 |
| davechen1y | but i will check | 01:16 |
| davechen1y | that bloody check | 01:16 |
| davechen1y | it was a stalemate for months | 01:16 |
| davechen1y | if he's broken the vfp checking i'll be royally pissed | 01:16 |
| mwhudson | davechen1y: fair enough | 01:17 |
| davechen1y | minux always wants the most complete solution | 01:18 |
| davechen1y | even if it is 10x more complicated | 01:18 |
| davechen1y | hmm, nope, that's not it | 01:18 |
| davechen1y | it's some subtle shit between running inside go tool dist test | 01:19 |
| davechen1y | and just running the shell script directly | 01:19 |
| miken | thumper: did those logs have the info you needed for bug 1494542? | 01:21 |
| mup | Bug #1494542: config-changed error does not cause error state <juju-core:In Progress by thumper> <juju-core 1.24:In Progress by thumper> <juju-core 1.25:In Progress by thumper> <https://launchpad.net/bugs/1494542> | 01:21 |
| mwhudson | davechen1y: that's pretty messed up | 01:21 |
| thumper | miken: still evaluating, lots of calls first thing today | 01:22 |
| thumper | miken: definitely useful though | 01:25 |
| thumper | miken: I'm trying to work out now why it has logged what it logged | 01:25 |
| thumper | miken: the uniter did enter error state, but it then immediately went to running | 01:25 |
| thumper | trying to work out why now | 01:25 |
| miken | Great (wasn't sure if I'd set the debug env option too late to grab the useful bits) | 01:27 |
| thumper | wallyworld: hey, I have veebers over for a visit, catch up later this afternoon? | 01:31 |
| wallyworld | thumper: sure, ok, just ping | 01:31 |
| davechen1y | mwhudson: you were right | 01:40 |
| davechen1y | it was the goarm=5 | 01:40 |
| davechen1y | but not in the way we expected | 01:40 |
| mwhudson | davechen1y: haha wtf | 01:57 |
| davechen1y | keep it simple, ffs | 02:01 |
| mwhudson | davechen1y: talking of minux his comment on https://go-review.googlesource.com/#/c/14635/2 is fairly out of left field | 02:05 |
| thumper | miken: found the problem | 02:09 |
| davechen1y | mwhudson: honestly, it's easier just avoid the conversation sometimes | 02:09 |
| thumper | miken: juju run bumps the unit out of the error status | 02:09 |
| mwhudson | davechen1y: yeah i only replied because i was replying to ian anyway | 02:09 |
| davechen1y | arguing doesn't change his position | 02:09 |
| miken | thumper: wow - always, or just in some special condition there? | 02:09 |
| thumper | miken: unknown just yet... | 02:09 |
| thumper | miken: it never used to record what it was doing | 02:10 |
| thumper | miken: I'm guessing this changed when the agent-status stuff was added | 02:10 |
| thumper | miken: appears to be always just now | 02:10 |
| * thumper continues looking | 02:10 | |
| miken | ack, thanks thumper | 02:10 |
| thumper | wallyworld: can we chat about this uniter issue, I think you know that bit of code more now | 02:14 |
| wallyworld | thumper: sure, just otp right now | 02:14 |
| wallyworld | finished soon | 02:14 |
| thumper | kk | 02:19 |
| * thumper goes to make a coffee | 02:19 | |
| wallyworld | thumper: finished meeting now | 02:36 |
| thumper | ok | 02:36 |
| wallyworld | what's the issue? | 02:36 |
| wallyworld | the config eerror one? | 02:36 |
| thumper | wallyworld: just need to deal with menn0 first :) | 02:37 |
| wallyworld | sure, i might grab a quick bite to eat | 02:37 |
| thumper | wallyworld: ping when you're free | 02:53 |
| wallyworld | thumper: ok, meet you in 1:1 in a minute | 02:53 |
| === axw_ is now known as axw | ||
| thumper | wallyworld: oh FFS, there is no way to get the current UnitStatus through the uniter API | 03:32 |
| wallyworld | oh really | 03:33 |
| thumper | sorry, AgentStatus | 03:33 |
| wallyworld | let me check | 03:33 |
| thumper | you can get UnitStatus but not AgentStatus | 03:33 |
| wallyworld | thumper: damn, yeah, you can set agent status | 03:34 |
| wallyworld | never was a need for it till now | 03:34 |
| thumper | yeah | 03:35 |
| thumper | bugger! | 03:35 |
| menn0 | axw: you got a moment? | 03:45 |
| axw | menn0: what's up? | 03:54 |
| menn0 | axw: did you create configInternal.SetAPIHostPorts? | 03:55 |
| menn0 | in agent/agent.go | 03:55 |
| axw | menn0: erm possibly, can't remember. there were a couple of people doing things related to that. why? | 03:56 |
| menn0 | i've been dealing with a broken IS env | 03:56 |
| menn0 | it wasn't the root cause but the way this method works made things worse | 03:57 |
| menn0 | Two issues | 03:57 |
| menn0 | 1. it modifies the list of API addresses just before updating the config but without telling anyone. | 03:57 |
| menn0 | So the logs emitted by apiaddressupdater are lies | 03:58 |
| menn0 | The API addresses it logs are being set aren't the actual ones that get written. | 03:58 |
| menn0 | this made the issue I was looking at somewhat harder to diagnose | 03:58 |
| menn0 | 2. It only writes out one address per server. Any reason it shouldn't write out every cloud local address of each server? | 03:59 |
| menn0 | In the case of the problem I was looking at, the LXC bridger address filtering wasn't working (I now know why, separate issue) | 03:59 |
| menn0 | so there was the LXC bridge address and the actual API server address | 04:00 |
| menn0 | and it was picking the LXC bridge address because it sorted first | 04:00 |
| menn0 | if it had written out both the env would have been ok | 04:00 |
| axw | menn0: I don't recall why only one is set... where is it only writing one? I can't see that bit of code | 04:01 |
| axw | menn0: oh I see | 04:01 |
| axw | menn0: misread | 04:01 |
| axw | menn0: I can't think of any reason why we shouldn't try them all | 04:02 |
| menn0 | servers has one element per server | 04:02 |
| menn0 | each element is a list of addresses for that server | 04:02 |
| axw | menn0: IIRC we try them all in parallel anyway | 04:03 |
| menn0 | axw: ok cool. i'll write up ticket about that | 04:03 |
| menn0 | axw: we do try them in parallel | 04:03 |
| menn0 | axw: and what about the lack of visibility with the filtering? I was thinking the filtered list should be returned or the filtering should be moved to outside SetAPIHostPorts. | 04:04 |
| axw | menn0: looking at that now, one minute | 04:04 |
| menn0 | axw: I looked at reading the config back out in apiaddressupdater - it's doable but more work than I realised | 04:05 |
| menn0 | axw: a number of interfaces need updating | 04:05 |
| menn0 | axw: it's probably cleaner ot have SetAPIHostPorts return the filtered list | 04:06 |
| axw | menn0: I think my thinking was that the filtering of internal addresses was particular to the consumer of the apiaddressupdater worker (i.e. the agent) | 04:07 |
| axw | menn0: the other filtering in apiaddressupdater was added later. originally it was just a dumb proxy | 04:09 |
| axw | menn0: having SetAPIHostPorts return the filtered list sounds fine to me | 04:09 |
| menn0 | axw: ok sounds good | 04:10 |
| menn0 | axw: thanks | 04:10 |
| axw | menn0: cheers. sorry for the confusing code/logging | 04:11 |
| menn0 | axw: np. it's one of those things that you only realise is problematic once you're trying to debug an issue around it. | 04:11 |
| miken | thumper: So we should be able to `juju run` commands while the unit is in an error state? I expected to be able to `juju ssh` (as it's not a hook context), but assumed juju run should fail if the unit is in an error state? | 04:14 |
| miken | thumper: certainly in our case, we only want to do the juju run commands if unit is not in an error state, but I can imagine there are scenarious where you want to juju run to fix an error state, or similar. | 04:14 |
| mup | Bug #1497094 opened: SetAPIHostPorts shouldn't record just one address per API server <juju-core:Triaged by menno.smits> <juju-core 1.24:Triaged by menno.smits> <juju-core 1.25:Triaged by menno.smits> <https://launchpad.net/bugs/1497094> | 04:34 |
| mup | Bug #1497098 opened: Addresses logged by apiaddressupdater aren't accurate <juju-core:New for menno.smits> <https://launchpad.net/bugs/1497098> | 04:34 |
| mup | Bug #1497094 changed: SetAPIHostPorts shouldn't record just one address per API server <juju-core:Triaged by menno.smits> <juju-core 1.24:Triaged by menno.smits> <juju-core 1.25:Triaged by menno.smits> <https://launchpad.net/bugs/1497094> | 04:37 |
| mup | Bug #1497098 changed: Addresses logged by apiaddressupdater aren't accurate <juju-core:New for menno.smits> <https://launchpad.net/bugs/1497098> | 04:37 |
| thumper | miken: yes, we should be able to juju run things | 04:39 |
| thumper | miken: the problem is it doesn't set the state back to what it was | 04:39 |
| thumper | I'm working on it, but it isn't a quick fix unfortunately | 04:39 |
| miken | thumper: I'm not blocked on it at all - so no pressure here. I was just surprised by the comment on the bug that the intent is in fact to execute the juju run when the unit is in an error state. Great. | 04:40 |
| mup | Bug #1497094 opened: SetAPIHostPorts shouldn't record just one address per API server <juju-core:Triaged by menno.smits> <juju-core 1.24:Triaged by menno.smits> <juju-core 1.25:Triaged by menno.smits> <https://launchpad.net/bugs/1497094> | 04:43 |
| mup | Bug #1497098 opened: Addresses logged by apiaddressupdater aren't accurate <juju-core:New for menno.smits> <https://launchpad.net/bugs/1497098> | 04:43 |
| === urulama__ is now known as urulama | ||
| thumper | miken: it is entirely valid though in general to allow juju run and juju actions while in an error state | 05:21 |
| * thumper has had a very interrupted afternoon | 05:21 | |
| thumper | will attempt some more work later | 05:21 |
| thumper | have a good weekend folks | 05:21 |
| mup | Bug #1496639 changed: juju get incorrectly reports boolean default values <canonical-bootstack> <juju-core:Invalid by menno.smits> <https://launchpad.net/bugs/1496639> | 06:22 |
| frobware | axw, thanks for the review. what's the procedure from here to getting this merged? Do I need to wait for other reviews? +2? | 07:55 |
| axw | frobware: no worries, thanks for catching it. nope, only one LGTM is required. there was talk of using +1/+2 recently, but unless you see +1 or +2 in a review, assume a ship it is +2 | 07:55 |
| axw | frobware: +1 meaning "looks ok, get another opinion", +2 meaning "ship it" | 07:56 |
| axw | frobware: have you merged a PR into juju before? you just need to add $$merge$$ as a comment on github | 07:57 |
| frobware | axw, nope, first one. whoop! :) | 07:57 |
| axw | frobware: yeah, I ruined your other first one, sorry about that ;) | 07:57 |
| frobware | axw, probably very wise... | 07:58 |
| frobware | axw, so post $$merge$$ what happens? ci jobs run unit tests and ci tests before actually merging? | 08:00 |
| axw | frobware: there's a bot watching the PRs. it'll see the $$merge$$, and check that master isn't blocked (critical regressions block master; when you fix them there's another special string to add to the comment). if it's not blocked, it'll start a job on jenkins (juju-ci.vapour.ws). the jenkins job will pull master, merge in your branch locally, run unit tests, and if all is well it'll merge into master | 08:02 |
| frobware | axw, so the "other" ci tests are orthogonal to that, where other != unit tests? | 08:03 |
| axw | frobware: there's also a periodic CI job in jenkins which runs various functional tests, e.g. upgrades | 08:03 |
| frobware | axw, aha | 08:03 |
| axw | frobware: that one doesn't gate landings BTW, that's asynchronous | 08:04 |
| frobware | axw, ack | 08:04 |
| axw | if CI picks up an error later, a critical regression will be logged and the branch will become blocked until it's fixed | 08:05 |
| ashipika | frobware: one minor comment.. otherwise LGTM.. | 08:08 |
| frobware | dooferlad, fwereade: standup? | 09:04 |
| dooferlad | frobware: thought I was in it | 09:04 |
| frobware | dooferlad, is friday always a different HO link? | 09:05 |
| frankban | dooferlad: hi, could you please take a look at http://reviews.vapour.ws/r/2710/ ? it's part of an ongoing work for supporting bundle deployment, and it's proposed against a feature branch | 10:09 |
| dooferlad | frobware: looking | 10:09 |
| dooferlad | frankban: looking | 10:10 |
| frankban | dooferlad: thanks! | 10:11 |
| dooferlad | (sorry frobware - tab completion without brain) | 10:11 |
| mup | Bug #1497229 opened: apiserver: TestAgentConnectionsShutDownWhenStateDies is very slow <unit-tests> <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1497229> | 11:08 |
| mup | Bug #1497229 changed: apiserver: TestAgentConnectionsShutDownWhenStateDies is very slow <unit-tests> <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1497229> | 11:11 |
| mup | Bug #1497229 opened: apiserver: TestAgentConnectionsShutDownWhenStateDies is very slow <unit-tests> <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1497229> | 11:20 |
| mup | Bug #1497241 opened: look who's back <juju-core:New> <https://launchpad.net/bugs/1497241> | 11:44 |
| mup | Bug #1497241 changed: look who's back <juju-core:New> <https://launchpad.net/bugs/1497241> | 11:47 |
| mup | Bug #1497241 opened: look who's back <juju-core:New> <https://launchpad.net/bugs/1497241> | 11:53 |
| wallyworld | frobware: just fyi, i fixed the milestone on bug 1496750 | 12:17 |
| mup | Bug #1496750: Failed worker can result in large number of goroutines and open socket connections and eventually gets picked on by the OOM killer <juju-core:Fix Committed by frobware> <juju-core 1.25:Fix Committed by frobware> <https://launchpad.net/bugs/1496750> | 12:17 |
| wallyworld | the milestone should be 1.25-beta1 | 12:17 |
| frobware | wallyworld, thx | 12:18 |
| wallyworld | as the fix was committed to the 1.25 branch prior to beta1 shipping | 12:18 |
| frobware | wallyworld, from the bug report how do you get to the PR that fixed the issue? | 12:22 |
| frobware | wallyworld, I didn't see any obvious link | 12:23 |
| wallyworld | frobware: sadly, we lost that ability once we were told to move to github | 12:25 |
| wallyworld | so it has to be added manually | 12:25 |
| wallyworld | paste the url into a bug comment | 12:25 |
| frobware | yuck | 12:25 |
| wallyworld | yeah | 12:25 |
| wallyworld | lp is great | 12:26 |
| wallyworld | having 2 systems means we get a bit of friction | 12:26 |
| frobware | dooferlad, have some time to HO w.r.t.1416928 | 12:40 |
| dooferlad | frobware: sure, give me a moment or two to get a glass of water and task switch. | 12:41 |
| frobware | dooferlad, or we just schedule in a bit, your call. | 12:45 |
| frobware | dooferlad, don't want to context switch unnecessarily | 12:45 |
| dooferlad | frobware: now is fine. | 12:48 |
| frobware | dooferlad, great! https://plus.google.com/hangouts/_/canonical.com/juju-sapphire | 12:49 |
| TheMue | dooferlad: thx for merging my PR. and greetings from my gardening ;) | 13:15 |
| * TheMue 's current change is moving a lot of plants inside the garden | 13:18 | |
| katco | natefinch: hey just saw you declined this morning's stand-up? not going to be there? | 14:03 |
| natefinch | katco: did I? | 14:04 |
| natefinch | katco: not intentionally. brt | 14:04 |
| katco | natefinch: looks like | 14:04 |
| mup | Bug #1497297 opened: TestFindToolsExactInStorage fails for some archs Again <blocker> <ci> <precise> <regression> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1497297> | 14:08 |
| mup | Bug #1497301 opened: mongodb3 SASL authentication failure <ci> <mongodb> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1497301> | 14:08 |
| mup | Bug #1497297 changed: TestFindToolsExactInStorage fails for some archs Again <blocker> <ci> <precise> <regression> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1497297> | 14:11 |
| mup | Bug #1497301 changed: mongodb3 SASL authentication failure <ci> <mongodb> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1497301> | 14:11 |
| mup | Bug #1497297 opened: TestFindToolsExactInStorage fails for some archs Again <blocker> <ci> <precise> <regression> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1497297> | 14:18 |
| mup | Bug #1497301 opened: mongodb3 SASL authentication failure <ci> <mongodb> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1497301> | 14:18 |
| katco | wwitzel3: at any rate, if you end up getting a patch, just go ahead and land it for 1.25-beta1. no reason not to | 14:25 |
| mup | Bug #1497312 opened: make assignment of units to machines use a worker <juju-core:New> <https://launchpad.net/bugs/1497312> | 14:42 |
| mup | Bug #1497316 opened: TestUniterSteadyStateUpgrade permission problem <ci> <intermittent-failure> <windows> <juju-core:Incomplete> <https://launchpad.net/bugs/1497316> | 14:42 |
| natefinch | katco: it looks like somehow I got set to "no" on all the standups, but I can't figure out how to change that back | 15:10 |
| cherylj | Can I get a review for the blocker? http://reviews.vapour.ws/r/2714/ | 15:23 |
| natefinch | cherylj: ship it! | 15:24 |
| cherylj | thanks natefinch | 15:24 |
| mup | Bug #1497351 opened: Cloudsigma 403 destroy instance <cloudsigma-provider> <destroy-environment> <juju-core:Triaged> <https://launchpad.net/bugs/1497351> | 16:06 |
| mup | Bug #1497351 changed: Cloudsigma 403 destroy instance <cloudsigma-provider> <destroy-environment> <juju-core:Triaged> <https://launchpad.net/bugs/1497351> | 16:09 |
| mup | Bug #1497351 opened: Cloudsigma 403 destroy instance <cloudsigma-provider> <destroy-environment> <juju-core:Triaged> <https://launchpad.net/bugs/1497351> | 16:18 |
| mup | Bug #1497351 changed: Cloudsigma 403 destroy instance <cloudsigma-provider> <destroy-environment> <juju-core:Triaged> <https://launchpad.net/bugs/1497351> | 16:24 |
| mup | Bug #1497351 opened: Cloudsigma 403 destroy instance <cloudsigma-provider> <destroy-environment> <juju-core:Triaged> <https://launchpad.net/bugs/1497351> | 16:27 |
| mup | Bug #1497355 opened: TestCollectWorkerStarts failed to instantiate metric recorder <ci> <intermittent-failure> <unit-tests> <wily> <juju-core:Triaged by cmars> <https://launchpad.net/bugs/1497355> | 16:30 |
| katco | natefinch: need rubber stamp for forward-port: http://reviews.vapour.ws/r/2715/ | 17:20 |
| katco | natefinch: also for master: http://reviews.vapour.ws/r/2716/ | 17:25 |
| natefinch | katco: I think we had said that forward ports didn't need reviews unless there were non-trivial merges that needed to be made | 17:29 |
| natefinch | katco: but rubber stamped anyway :) | 17:31 |
| katco | natefinch: ah, missed that. ty | 17:31 |
| katco | natefinch: will have other patches soon for easy reviews | 17:32 |
| natefinch | katco: cool | 17:33 |
| katco | natefinch: any idea what cpupower actually represents? | 17:46 |
| katco | natefinch: nm, juju help constraints explains | 17:47 |
| katco | natefinch: actually, looks like amazon stopped using ecus... do you think it's safe to omit that for the new type? | 17:52 |
| katco | natefinch: jees, yet again nm. looks like they've stopped using it, but they still list it: http://aws.amazon.com/ec2/pricing/ | 17:55 |
| katco | natefinch: quick review: http://reviews.vapour.ws/r/2717/ | 17:59 |
| natefinch | katco: looking | 18:04 |
| katco | natefinch: ty | 18:04 |
| natefinch | katco: ship it | 18:08 |
| katco | natefinch: ty again. btw not finding this mythical default variable, so do you have your fix handy? | 18:08 |
| katco | natefinch: re: default ec2 type | 18:08 |
| natefinch | katco: just change default CPUPower to 300 | 18:11 |
| * katco cringes | 18:12 | |
| natefinch | what, isn't that obvious? ;) | 18:12 |
| katco | natefinch: i wonder if i could do something still small, but a little more intentful | 18:12 |
| natefinch | actually 201-300 also works | 18:12 |
| natefinch | pick 243 and see how long it takes someone to notice | 18:12 |
| katco | natefinch: e.g. if no constraints are set, set a constraint of instance-type ? | 18:12 |
| natefinch | katco: the problem is that if someone sets like... 1 cpu core | 18:13 |
| natefinch | you still want it to pick m3.medium | 18:13 |
| katco | natefinch: but then that's not the default, right? they've set constraints? | 18:13 |
| natefinch | katco: but the way it works now, the CPUPower is the magic number that keeps you from accidentally getting a tiny instance. | 18:14 |
| katco | natefinch: (sigh) k, i'll maybe address that in my 1.26 branch | 18:14 |
| natefinch | katco: yes... I'm not saying it's good... just saying that tweaking the minimum default CPU power will be consistent with the way it works now. | 18:15 |
| cmars | could use a review of a simple timing fix if someone has a moment, http://reviews.vapour.ws/r/2719/ | 18:32 |
| katco | cmars: will look in a sec | 18:36 |
| katco | natefinch: curious... it's picking a c1.medium with defaultCpuPower set to 500 | 18:40 |
| natefinch | katco: that's odd. Is this live testing or running unit tests? | 18:42 |
| katco | natefinch: live testing | 18:42 |
| katco | natefinch: sorry, defaultCpuPower set to 300 | 18:42 |
| natefinch | katco: oh yeah... I remember that happening.. | 18:42 |
| natefinch | katco: I remember there were two things I had to do... I also had to set default mem to 2048 | 18:43 |
| natefinch | (to exclude the c1.medium) | 18:43 |
| natefinch | katco: since it's cheaper than the m3.medium | 18:44 |
| natefinch | katco: except no, it looks more expensive | 18:45 |
| natefinch | katco: weird... it shouldn't pick the c1.medium since it's more expensive | 18:46 |
| katco | natefinch: not so weird. the constraints code has all kinds of implicit obfuscation | 18:47 |
| natefinch | katco: but I remember that happening when I was working on the code too. | 18:47 |
| natefinch | yep | 18:47 |
| natefinch | exactly what you were fixing | 18:47 |
| katco | natefinch: bleh... the problem is we need a concept of "discouraged usage" | 18:54 |
| natefinch | katco: yep, I was thinking the exact same thing when I was looking at it. | 18:56 |
| katco | natefinch: alas, another thing for the 1.26 patch | 18:56 |
| natefinch | katco: yeop | 18:56 |
| katco | natefinch: lol if i specify instance-type=m3.medium in the live test: "no instance types in test matching constraints "instance-type=m3.medium"" | 19:23 |
| mgz | katco: in all regions? | 19:23 |
| natefinch | :p | 19:23 |
| katco | mgz: of course i have no idea because this test is sitting on a giant stack of layered testing framework | 19:24 |
| mgz | :) | 19:24 |
| natefinch | katco: yeah, the tests don't use the real list of instance types.... this is exactly the problem I was complaining about before. We mock them out.... though I can't imagine why we're mocking out static data. | 19:25 |
| katco | natefinch: time for actual bootstrapping | 19:26 |
| natefinch | effectively: | 19:26 |
| natefinch | var sky color = "blue" | 19:26 |
| natefinch | func TestSkyColor(t *testing.T) { | 19:26 |
| natefinch | sky = "red" | 19:26 |
| natefinch | ... | 19:26 |
| natefinch | } | 19:26 |
| katco | natefinch: last review: http://reviews.vapour.ws/r/2720/ | 20:24 |
| katco | natefinch: also, how's the fix coming? | 20:35 |
| natefinch | katco: coming... gonna take some time over the weekend, but I kinda expected that with the amount I've been out this week. | 20:37 |
| katco | natefinch: k | 20:37 |
| katco | natefinch: time for a 25-line review? | 20:37 |
| natefinch | katco: yeah. | 20:38 |
| natefinch | katco: two things: one theoretical and one concrete | 20:43 |
| natefinch | katco: the theoretical is.... in theory, the memory and cpupower from the default type could still have us choosing a different default type | 20:43 |
| katco | natefinch: very true, but i thought that supported existing behavior: we don't specify a default type, just default constraints | 20:44 |
| katco | natefinch: this happens to select the correct thing until i can get the more comprehensive patch landed which should include "discouraged" types | 20:45 |
| natefinch | katco: ok... I'm just thinking that people might put too much faith in the fact that they're giving the memory and cpupower of a default type, but there's no real guarantee that the type you get out is the type you put in. | 20:46 |
| natefinch | katco: anyway, that's theoretical and not really a big deal | 20:46 |
| natefinch | katco: and actually the second one is probably also only theoretical, in practice (heh) | 20:47 |
| natefinch | katco: the code sets the memory constraint even if the CPU power was set... which could cause a different instance type to get chosen after this change | 20:48 |
| natefinch | katco: I kind of assume no one uses anything except maybe RAM as a constraint, and if they want to choose an instance type, they specify it with the instance type constraint. | 20:48 |
| katco | natefinch: hmm | 20:49 |
| natefinch | katco: I have a hard time believing anyone is out there going juju deploy mycharm --constraints=CPUPower=650 (or whatever) | 20:49 |
| katco | natefinch: well... isn't this still doing the right thing though? aren't we saying "this is juju's default minimum memory constraint"? | 20:50 |
| katco | natefinch: it's a new concept, i agree with that. | 20:50 |
| natefinch | katco: I guess that's true.... I guess we're already making it choose something different by default explicitly... m3.medium instead of m1.small | 20:51 |
| katco | natefinch: how's this: given this will change in 1.26, it's probably suitable for 1.25 | 20:51 |
| natefinch | katco: I think it'll be fine, yes. | 20:52 |
| natefinch | katco: at worst, .01% of our users will have to very slightly modify their scripts, which were probably being oddly AWS specific, without actually being AWS specific. | 20:53 |
| katco | natefinch: soo... shipit? | 20:55 |
| natefinch | katco: couple very minor comments posted | 20:57 |
| natefinch | katco: oh, also, I'd love love love a test that actually tests if you get m3.medium by default | 20:58 |
| natefinch | katco: but I understand that there may not be time for that, and we're not worse off than we were before. | 20:58 |
| katco | natefinch: so would i. i had one written up, but i'd have to delve into where those types are coming from | 20:58 |
| katco | natefinch: i can confirm manual testing proves it out though | 20:59 |
| natefinch | katco: yeah, that's how I was testing it, too. | 20:59 |
| perrito666 | I definitely hate mongo 3 | 20:59 |
| natefinch | katco: we can just hang our head in shame about the whole mess and fix it right in 1.26 | 20:59 |
| natefinch | gotta run | 21:03 |
| === natefinch is now known as natefinch-afk | ||
| alexisb | perrito666, I take it your having fun w/ the mongo 3.0 upgrade spike | 21:31 |
| perrito666 | alexisb: what in my comment lead you to use the word fun in that sentence :p ? | 21:32 |
| perrito666 | they very nicely changed this feature http://docs.mongodb.org/manual/core/authentication/#localhost-exception in which our whole replicaset initiation is based :p | 21:33 |
| mup | Bug #1497456 opened: TestResolveCharm regex mismatch <ci> <regression> <test-failure> <unit-tests> <juju-core:Triaged> <juju-core use-charm.v6-unstable:Triaged> <https://launchpad.net/bugs/1497456> | 21:40 |
| mup | Bug #1497456 changed: TestResolveCharm regex mismatch <ci> <regression> <test-failure> <unit-tests> <juju-core:Triaged> <juju-core use-charm.v6-unstable:Triaged> <https://launchpad.net/bugs/1497456> | 21:49 |
| mup | Bug #1497456 opened: TestResolveCharm regex mismatch <ci> <regression> <test-failure> <unit-tests> <juju-core:Triaged> <juju-core use-charm.v6-unstable:Triaged> <https://launchpad.net/bugs/1497456> | 22:01 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!