| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-25 | |||
| 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 | bauzas | but those whole tests are so opininiated about what should fail and what should succeed | |
| 16:14:38 | dansmith | bauzas: you mean what compute reports in that functional test, yes? | |
| 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 | bauzas | edleafe: since we default verifying those resources, we could have to change the tests | |
| 16:15:43 | dansmith | bauzas: but that test is relying on overcommitting the node with a single vm right? | |
| 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? | |
| 16:22:07 | johnthetubaguy | the complexity is certainly less than having to check if the core filter is enabled | |
| 16:22:37 | bauzas | dansmith: indeed | |
| 16:22:47 | dansmith | johnthetubaguy: and more intuitive than having to enable a legacy filter to make the math work like you (should) expect for the new system | |
| 16:23:19 | dansmith | bauzas: okay I'll reply to the ML thread then | |
| 16:23:26 | bauzas | dansmith: https://github.com/openstack/nova/blob/master/nova/tests/functional/test_server_group.py#L683 is an example of what I mean by "opiniated" | |
| 16:28:30 | sfinucan | diana_clarke: Left a comment on https://review.openstack.org/#/c/421333. I can move onto the rest of the series once that's addressed | |
| 16:33:49 | bauzas | dansmith: are you done with replying to my email ? because I can do that by me, I found the solution for the test | |
| 16:33:55 | dansmith | just did | |
| 16:33:58 | bauzas | okay | |
| 16:34:24 | bauzas | I'm just considering how to patch correctly the FakeDriver within that testcase | |
| 16:34:47 | dansmith | can't you change the request instead of the fake driver? | |
| 16:35:19 | bauzas | dansmith: I would neither change the fake driver itself or the request | |
| 16:35:31 | bauzas | dansmith: the test is RAM-bounded, I'd like to keep it | |
| 16:35:50 | bauzas | so my solution is to have enough CPU-filled computes | |
| 16:36:15 | bauzas | so the test would still assume which host would fail and which not but still only based on one metric, which is RAM | |
| 16:36:25 | bauzas | that's the less invasive | |
| 16:36:31 | dansmith | seems easiest to just request 100% of the compute to fill it, bu okay | |
| 16:37:17 | bauzas | dansmith: it's sending 3 requests with the same big flavor with the assumption that only RAM would fail | |
| 16:37:48 | cfriesen | has anyone heard of virt.libvirt.guest.Guest.get_vcpus_map() failing with "exception: Requested operation is not valid: cpu affinity is not supported" ? Normally this works fine, I just saw it once during a stress test. | |
| 16:38:27 | sahid | cfriesen: are you in TCG? | |
| 16:38:56 | sahid | you should to verify first in you have well configured nova.conf to use kvm | |
| 16:39:03 | sahid | should verify | |
| 16:40:46 | cfriesen | sahid: this is real hardware with kvm | |
| 16:41:26 | cfriesen | sahid: most of the time it works fine on this system, but I saw this log once during a test of multiple live migrations. | |
| 16:42:18 | sahid | cfriesen: hum.. so i would suggest to verify whether the intel VT module is well loaded, it's probably something around that | |
| 16:43:19 | sahid | if it's not configuration issue, virt_type=kvm, the module well loaded so you will probably have to report a bug since that seems weird | |
| 16:43:51 | cfriesen | sahid: I'm pretty sure that the compute node stayed up and running during the test, but I'll check. | |
| 16:44:21 | sahid | cfriesen: also are you trying to run something related to NUMA ? | |
| 16:44:58 | cfriesen | sahid: this is on Mitaka, so I'm not sure how useful a bug report would be. CPU pinning would be enabled, so it'll be setting up InstanceNUMATopology | |
| 16:46:59 | cfriesen | actually, checking the logs more closely this message occurred multiple times...will dig a bit further, see if I can find a pattern. | |
| 16:50:16 | sfinucan | vladikr: The reno in https://review.openstack.org/#/c/405951/ is a little confusing | |
| 16:50:20 | bauzas | dansmith: thanks for your email, appreciated | |
| 16:50:45 | andreas_s | thorst_, FYI https://review.openstack.org/#/c/425279/ | |
| 16:50:45 | bauzas | dansmith: I'm about to find a solution, but since we also have the grenade issue, just lemme know if you wanna recheck anytime | |
| 16:50:59 | andreas_s | thorst_, it's not as nice than yours, but it does the job automatically | |
| 16:51:03 | sfinucan | Per my understanding, we want this feature because we want the set the VLAN tag inside the guest OS | |