| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-25 | |||
| 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? | |
| 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 | 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:45 | andreas_s | thorst_, FYI https://review.openstack.org/#/c/425279/ | |
| 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 | |
| 16:51:05 | vladikr | sfinucan, hmm, okay.. how can I clarify it? | |
| 16:51:16 | andreas_s | thorst_, basically it's the generated file included into an rst... | |
| 16:51:25 | dansmith | bauzas: I already did earlier but the gate is pretty slammed | |
| 16:51:34 | bauzas | ok | |
| 16:51:36 | sfinucan | ...but there's no way to access this from inside the instance without this feature | |
| 16:51:41 | sfinucan | vladikr: Is that correct? | |
| 16:52:10 | cfriesen | sahid: It appears to be a race between the resource audit and an instance that is just starting up. I suspect the domain hasn't yet gotten to a state where it will properly respond to this request. | |
| 16:52:34 | cfriesen | sahid: will need to reproduce on newer code before opening a bug report. | |
| 16:53:56 | vladikr | sfinucan, pretty much, I think. We can't set anything in side the guest. We want this field to be exposed so the guest so it will set the vlan on a virtual interface - if it need it to be set | |
| 16:54:53 | openstackgerrit | Ed Leafe proposed openstack/nova: placement: RT now adds proper Ironic inventory https://review.openstack.org/404472 | |
| 16:55:09 | vladikr | sfinucan, so we just want to add additional parameter to the device metadata (that we have exposed to the guests with the device tagging work) | |
| 16:55:20 | sahid | cfriesen: ok cool, just as a sidenote since you spoke about live-migration: https://review.openstack.org/#/c/419479/ | |
| 16:55:28 | edleafe | cdent: Fixed your concern ^^ | |
| 16:56:03 | cdent | edleafe: thanks. was I crazy or insightful? | |
| 16:56:39 | edleafe | Those are not mutually exclusive | |
| 16:56:42 | sfinucan | vladikr: Right. So this sentence would suggest otherwise >>> "the VLAN configuration for the guest's virtual interfaces associated with such devices, can only be done within the guest instance itself." | |
| 16:57:01 | sfinucan | at least to me, that suggests the guest can now configure VLANs for these interfaces | |
| 16:57:06 | cdent | edleafe: was I right or wrong? | |
| 16:57:31 | edleafe | cdent: you were right | |
| 16:57:52 | vladikr | sfinucan, well it says that if you have assigned an sriov device to the guest you will get a virtual interface inside the guest | |
| 16:58:14 | cfriesen | sahid: thanks for the reference | |
| 16:58:25 | sfinucan | vladikr: Right, and it's the guest's responsibility to set the VLAN field on that virtual interface? | |