| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-25 | |||
| 15:57:33 | mdbooth | artom: Awesome. Wasn't sure what the resolution was, just thought I'd throw in a data point :) | |
| 15:57:47 | edleafe | dansmith: ok, so we have "bonkers", "crazy people", and "not very smart" to describe that | |
| 15:57:57 | edleafe | dansmith: you win the prize for most polite | |
| 15:57:59 | dansmith | edleafe: artom cdent: If someone had a problem with this, we could allow setting insanity_mode=on, which would report max_unit=N*allocation_ratio | |
| 15:58:18 | dansmith | edleafe: I'd like to change my answer to "fucking stupid" | |
| 15:58:49 | cdent | laaaaaadies and gentleman in a last minute change, dansmith wins | |
| 15:59:01 | bauzas | we don't use CoreFilter in the default list of filters | |
| 15:59:04 | bauzas | soooooo great | |
| 15:59:21 | dansmith | bauzas: that's not news, is it? | |
| 15:59:30 | bauzas | it is to me | |
| 15:59:38 | bauzas | I thought the gate was special | |
| 15:59:55 | bauzas | but that we allowed corefilter by default | |
| 16:00:01 | bauzas | I'm utterly surprised | |
| 16:00:35 | bauzas | so I'm just discovering that we *never* verified in Newton the CPU resources | |
| 16:00:41 | bauzas | unless you explicitely asked for | |
| 16:01:09 | bauzas | because if so, the CoreFilter would deny like the placement engine | |
| 16:01:20 | bauzas | that's even worst ! | |
| 16:01:28 | bauzas | holy shit | |
| 16:02:04 | bauzas | pardon my language | |
| 16:02:15 | bauzas | dansmith: ^ | |
| 16:02:32 | edleafe | bauzas: at least curse in French | |
| 16:02:45 | bauzas | so, just to be clear, lemme restate for the audience | |
| 16:02:47 | dansmith | even worse in what way? that it's a change? | |
| 16:03:07 | bauzas | in Newton, we totally accept that we can return a destination that doesn't satisfy the vCPU requirements | |
| 16:03:31 | bauzas | that's worst because that's changing the scheduler behaviour | |
| 16:03:48 | edleafe | Returning a destination is an implementation detail, not a behavior | |
| 16:04:09 | bauzas | placing an instance on a target is a behavioural choice | |
| 16:04:15 | dansmith | bauzas: but the whole point of placement is making better decisions right? | |
| 16:04:19 | edleafe | If anything, the change should reduce the number of retries | |
| 16:04:21 | dansmith | not less opinionated ones, but better ones | |
| 16:04:48 | edleafe | dansmith: jinx (sorta) | |
| 16:04:53 | dansmith | aye | |
| 16:06:32 | bauzas | edleafe: dansmith: the fun with that is that the problem still remains for RAMFilter | |
| 16:06:51 | dansmith | but really, | |
| 16:06:55 | bauzas | even if we say "fair enough, we don't need to advert operators to modify their ratios for cpu" | |
| 16:07:01 | bauzas | the problem remains for ram | |
| 16:07:02 | dansmith | overcommitting the whole node in a single VM is just nuts | |
| 16:07:10 | dansmith | eve more nuts than cpu | |
| 16:07:27 | dansmith | if we want to offer an insanity_mode config option, then let's do it | |
| 16:07:35 | dansmith | and make it clear what it is | |
| 16:07:49 | dansmith | I'll write the patch | |
| 16:08:23 | bauzas | I'm still wondering why we never used CoreFilter in that case | |
| 16:08:41 | dansmith | all I really care about is getting this patch in so we're not kicking it to another release | |
| 16:08:42 | edleafe | dansmith: "If you want to stick your fork into the electrical socket..." | |
| 16:08:51 | dansmith | edleafe: that can go in the help text | |
| 16:09:12 | bauzas | so you gonna rev'd my change? | |
| 16:09:30 | dansmith | it doesn't affect your change, right? it'd be a reporting change | |
| 16:09:48 | dansmith | but yes, if I need to write that patch to move us forward I'll do it | |
| 16:10:46 | edleafe | I think that's the wrong approach | |
| 16:11:18 | edleafe | It's not breaking anything | |
| 16:11:34 | dansmith | edleafe: you think what is wrong? allowing insanity_mode? | |
| 16:11:46 | edleafe | dansmith: yes | |
| 16:12:10 | edleafe | If someone is actively relying on this, they *should* fail | |
| 16:12:14 | dansmith | edleafe: IMHO, I'd wait for people to complain and then do it to get them out of hot water | |
| 16:12:15 | edleafe | and they should feel bad | |
| 16:12:18 | dansmith | hah | |
| 16:12:40 | dansmith | but if bauzas is going to rage quit now, then I could be persuaded to add it now | |
| 16:12:47 | dansmith | but I agree, it seems like making better choices to me | |
| 16:12:53 | bauzas | I'm not rage quitting, just exhausted | |
| 16:13:01 | dansmith | johnthetubaguy: were you one of the concerned porties/ | |
| 16:13:02 | dansmith | jeez | |
| 16:13:03 | dansmith | *parties? | |
| 16:13:12 | bauzas | because in particular, my f**** change is hitting a functional test issue | |
| 16:13:20 | bauzas | based on that particular assumption | |
| 16:13:30 | dansmith | bauzas: that's trivial to fix right? | |
| 16:13:42 | dansmith | that functional test is reporting something that depends on the broken behavior to work, right? | |
| 16:13:52 | bauzas | honestly? I dunno | |
| 16:14:10 | bauzas | we could fix up what the compute reports | |
| 16:14:18 | bauzas | that sounds the better approach | |
| 16:14:38 | dansmith | bauzas: you mean what compute reports in that functional test, yes? | |
| 16:14:38 | bauzas | but those whole tests are so opininiated about what should fail and what should succeed | |
| 16:14:46 | bauzas | dansmith: yup | |
| 16:14:54 | edleafe | bauzas: So you think that the test is absolutely correct in what it's testing? | |
| 16:15:20 | bauzas | edleafe: I just think that functional test is fine by me, it's just not taking care of other resources | |
| 16:15:23 | edleafe | bauzas: or could it be making the same incorrect assumption? | |
| 16:15:43 | dansmith | bauzas: but that test is relying on overcommitting the node with a single vm right? | |
| 16:15:43 | bauzas | edleafe: since we default verifying those resources, we could have to change the tests | |
| 16:15:47 | edleafe | Tests are code, and all code has bugs | |
| 16:16:05 | bauzas | dansmith: yup, it was just taking care of RAM previously | |
| 16:16:13 | dansmith | right, so the test is wrong | |
| 16:16:16 | dansmith | let's fix and move on | |
| 16:16:45 | dansmith | I, for one, am fairly concerned about what happens if we don't merge this code this cycle | |
| 16:16:48 | dansmith | I dunno about anyone else | |
| 16:17:10 | dansmith | so I'm really not looking to settle for not landing it for anything other than a major problem | |
| 16:17:33 | bauzas | dansmith: I don't disagree at all | |
| 16:17:46 | bauzas | I'm just focusing on the right path to success | |
| 16:18:29 | johnthetubaguy | dansmith: +1, I think we have to land it, warts and all | |
| 16:18:53 | dansmith | johnthetubaguy: so is RAX one that would care about not being able to overcommit the node with a single instance? | |
| 16:19:21 | johnthetubaguy | so I should be very specific on my concern | |
| 16:19:28 | johnthetubaguy | right now we don't run the core filter | |
| 16:19:40 | johnthetubaguy | so the overcomit raito is not set correctly | |
| 16:19:52 | johnthetubaguy | thats easily fixable, but does bend our upgrade rules a bit | |
| 16:20:25 | dansmith | johnthetubaguy: ah I see.. we start honoring a config variable that you may not have had to set before.. that's a rather small bend... | |
| 16:20:26 | johnthetubaguy | the 10vCPU VM on an 8pCPU host doesn't worry me | |
| 16:20:44 | dansmith | johnthetubaguy: it's also hard to know how we'd communicate that if we were giving a cycle for reprecation | |
| 16:21:02 | dansmith | johnthetubaguy: also, overcommit on cpu is set to something large by default isn't it? | |
| 16:21:07 | dansmith | 16 and 1.5 | |
| 16:21:18 | dansmith | so people with defaults are probably in the sane range already I'd imagine | |
| 16:21:40 | johnthetubaguy | true, that is quite high already | |
| 16:22:05 | dansmith | bauzas: are you working on fixing the test? | |