| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-05-30 | |||
| 14:39:08 | openstackgerrit | Jay Pipes proposed openstack/nova master: mirror nova host aggregate members to placement https://review.openstack.org/553597 | |
| 14:39:25 | mriedem | jaypipes: figured out massimo's cold migrate issue in the ML | |
| 14:39:34 | efried | bhagyashris: As for the second thing, not sure I can help without seeing the code. Can you upload your patch set? | |
| 14:41:50 | bhagyashris | efried: here is my second approach test case http://paste.openstack.org/show/722352/ | |
| 14:42:47 | bhagyashris | efried: under /nova/tests/functional/libvirt/test_rt_servers.py | |
| 14:42:47 | jaypipes | mriedem: I saw that. :) | |
| 14:43:01 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: Remove usage of migrateToURI{2} APIs https://review.openstack.org/567258 | |
| 14:43:32 | bhagyashris | efried: can you help me how i should install libvirt library in my functional venv | |
| 14:43:45 | efried | bhagyashris: Are you still getting that import error? | |
| 14:44:58 | stephenfin | bhagyashris: IIRC, you need to install the libvirt and python-libvirt packages using your package manager (apt, dnf, yum...) | |
| 14:45:06 | efried | bhagyashris: You would do it like this: | |
| 14:45:06 | efried | bash # enter a new subshell | |
| 14:45:06 | efried | source .tox/functional/bin/activate # enter the `functional` venv | |
| 14:45:06 | efried | pip install libvirt # install the lib into the venv | |
| 14:45:06 | efried | exit # leave the venv by leaving the subshell | |
| 14:45:18 | efried | stephenfin: Oh, they're apt, not pip? | |
| 14:45:20 | openstackgerrit | Stephen Finucane proposed openstack/nova-specs master: Add 'numa-aware-vswitches' spec https://review.openstack.org/541290 | |
| 14:45:32 | efried | bhagyashris: Listen to stephenfin, not me. He would know better. | |
| 14:46:20 | stephenfin | efried: I think so, yeah. It's installed by default on Fedora, anyway | |
| 14:46:29 | dansmith | bhagyashris: what stephenfin said | |
| 14:47:54 | efried | stephenfin: If you're in a helpful mood, would you take a look at bhagyashris's paste above? What we're going for here is a functional test setup that uses the actual libvirt driver as much as possible, so that the compute node RP is created in placement, and update_provider_tree gets called by the RT on compute startup and periodics. | |
| 14:48:29 | mriedem | all of this request spec hydration code just needs to be burned out with acid/fire; i've had a todo on my list for awhile to actually do that, but... | |
| 14:48:41 | efried | and I don't know from libvirt, so don't really have a concept of how/where stuff needs to be mocked or whatever. | |
| 14:48:58 | stephenfin | efried: I thought functional tests were supposed to use fakelibvirt everywhere? | |
| 14:49:35 | stephenfin | i.e. you're testing everything in nova but nothing outside it, if possible. Integration tests (Tempest) are for testing the whole system | |
| 14:49:37 | efried | stephenfin: You mean nova.tests.unit.virt.libvirt.fakelibvirt.FakeLibvirtFixture ? | |
| 14:49:40 | stephenfin | Yup | |
| 14:49:47 | sahid | dansmith: what was the agreement regarding incrementing objects version for os-vif? | |
| 14:49:49 | stephenfin | Wait, lemme double check | |
| 14:49:50 | sahid | https://review.openstack.org/#/c/570959/1/os_vif/objects/vif.py | |
| 14:50:40 | stephenfin | efried: See nova/tests/functional/libvirt/test_numa_servers.py | |
| 14:50:58 | dansmith | sahid: what do you mean? that patch looks correct to me (wrt the version) | |
| 14:51:08 | dansmith | sahid: if it's an os-vif-specific thing, then I guess ask jaypipes | |
| 14:51:46 | sahid | dansmith: no it's not it's really about objects verion. I think you did not want that we incrmeent the version because that is not going to be shared by rpc | |
| 14:51:50 | sahid | or something like that, no? | |
| 14:52:06 | sahid | at least it's not right now | |
| 14:52:16 | openstackgerrit | Elod Illes proposed openstack/nova stable/pike: placement: Fix HTTP error generation https://review.openstack.org/571218 | |
| 14:52:26 | mriedem | i thought we tried to follow the normal object versioning in os-vif even if it's not going over the wire yet | |
| 14:52:33 | dansmith | sahid: but it could be serialized somewhere else at some point, like between neutron and nova | |
| 14:52:44 | dansmith | mriedem: right, I'm not sure why not, but maybe I'm missing something | |
| 14:53:22 | sahid | mriedem, dansmith ok so let's do that, seems reasonable yes | |
| 14:53:32 | stephenfin | mriedem, dansmith: Reworked the numa-aware-vswitch spec per our discussion in Vancouver. Lemme know if I missed anything | |
| 14:53:41 | stephenfin | Will start reworking the patches themselves shortly | |
| 14:53:48 | bhagyashris | efried, stephenfin: thanks checking for the same. | |
| 14:54:02 | mriedem | stephenfin: ok thanks, | |
| 14:54:08 | mriedem | got a couple of patches ahead of me yet | |
| 14:54:18 | stephenfin | ack | |
| 14:54:49 | dansmith | stephenfin: cool. given the complexity here, I think it probably makes sense to evaluate the spec and the code somewhat in parallel | |
| 14:55:21 | stephenfin | dansmith: Just to make sure, there isn't a deadline I need to wary of, in that case? | |
| 14:55:36 | dansmith | oh, maybe | |
| 14:55:58 | stephenfin | I'm also nervous of forgetting our learnings about not solving everything in the spec | |
| 14:56:17 | stephenfin | I think the code that I already have proves out the idea. Now I just need to shuffle about where I'm storing stuff | |
| 14:56:40 | stephenfin | (also, no spec = no runway slot) | |
| 15:01:00 | bauzas | gentle reminder for folks that the spec about multiple vGPU types has been updated https://review.openstack.org/#/c/557065/ | |
| 15:01:06 | bauzas | jaypipes: dansmith: ^ | |
| 15:02:21 | mriedem | stephenfin: spec freeze is june 7 | |
| 15:02:25 | mriedem | so you've got about a week | |
| 15:02:33 | stephenfin | to...? | |
| 15:02:38 | mriedem | get the spec approved | |
| 15:03:13 | stephenfin | That's in your hands then, I guess? I'll work on updating the code in the interim | |
| 15:03:17 | mriedem | probably not a bad idea to do another spec review sprint/flush in the coming week to get anything we want into rocky through before spec freeze | |
| 15:03:34 | mriedem | my volume multiattach enhancement spec has been waiting too | |
| 15:04:48 | bauzas | mriedem: you can review this easy spec for just a conf opt https://review.openstack.org/#/c/557065/ | |
| 15:05:11 | mriedem | i can add it to the queue | |
| 15:05:15 | cfriesen | mriedem: what are your thoughts on getting https://review.openstack.org/#/c/465787/ merged? | |
| 15:05:29 | bauzas | mriedem: fair enough | |
| 15:05:41 | cfriesen | mriedem: I guess you've got a todo in there still | |
| 15:05:52 | openstackgerrit | Vishakha Agarwal proposed openstack/python-novaclient master: No requirement of –all-tenants while listing servers https://review.openstack.org/569090 | |
| 15:05:53 | stephenfin | mriedem: I don't know how much use I'd be reviewing that. I've only reviewed patches for that stuff because ildikov wouldn't stop bugging me :) I can try though | |
| 15:06:12 | bauzas | mriedem: stephenfin: FWIW, I'm tempted to punt https://review.openstack.org/#/c/552924/ from Rocky and defer to Stein | |
| 15:06:15 | bauzas | jaypipes: ^ | |
| 15:06:43 | bauzas | because nested RPs is still in early bits, and because I shit have no time to further work on implementing it for Rocky anyway | |
| 15:06:57 | bauzas | so I'll work on providing a new rev' of course, but not prioritary | |
| 15:07:12 | stephenfin | bauzas: Wait, how does that compare with jaypipes' spec? | |
| 15:07:13 | ildikov | stephenfin: I can bug you again if that helps :) | |
| 15:07:14 | jaypipes | bauzas: I have a feeling tetsuro will have made significant progress on much of that in Rocky. | |
| 15:07:28 | jaypipes | stephenfin: the cpu-resources spec is about dedicated cores, not NUMA. | |
| 15:07:40 | jaypipes | dedicated and shared cores. | |
| 15:07:41 | mriedem | cfriesen: i would like to see it merged, so i don't have thoughts on my own patch :) | |
| 15:07:45 | mriedem | cfriesen: you should ask other cores | |
| 15:07:48 | bauzas | jaypipes: I looked at tetsuro's patches and those are still under review, right? | |
| 15:07:57 | jaypipes | bauzas: of course, yes | |
| 15:08:05 | bauzas | so, it's in my pipe | |
| 15:08:09 | mriedem | cfriesen: just throw it in the starlingx mega patch-o-doom and it will get reviews from at&t for sure! | |
| 15:08:11 | stephenfin | jaypipes: But you're using NUMA, no? | |
| 15:08:23 | jaypipes | bauzas: not just tetsuro, though. efried and Citrix guys are pushing ahead. | |
| 15:08:33 | bauzas | but my point is, nested resource providers is just incepted, and possibly vGPUs are the first usecases that'll use those | |
| 15:08:47 | mriedem | cfriesen: the todo is for future refactor | |
| 15:08:48 | stephenfin | jaypipes: e.g. https://review.openstack.org/#/c/555081/10/specs/rocky/approved/cpu-resources.rst@217 | |
| 15:08:51 | bauzas | jaypipes: I'm working on that too, remember | |
| 15:08:52 | jaypipes | stephenfin: that latest revision I tried to remove as much ass possible any mentions of NUMA in so much as extra specs or anything about the NUMATopologyFilter. | |
| 15:08:59 | mriedem | cfriesen: if i meant to hold up the patch on the todo, i would have wip'ed it | |
| 15:09:07 | cfriesen | mriedem: the plan is to submit individual small patches... Actually, we're already using your patch so it's already in the list. | |
| 15:09:17 | bauzas | jaypipes: http://lists.openstack.org/pipermail/openstack-dev/2018-May/130783.html | |
| 15:09:18 | mriedem | cfriesen: heh i know | |
| 15:09:19 | cfriesen | mriedem: yeah, I caught that on re-read | |
| 15:09:29 | bauzas | jaypipes: you possibly missed it | |
| 15:09:30 | jaypipes | bauzas: I'm not holding up progress on n-r-p's various efforts ongoing. | |
| 15:09:33 | mriedem | cfriesen: i just need to stab the starlingx thing at every opportunity | |
| 15:09:35 | jangutter | sahid: Apologies for side-tracking, but I've got a question regarding the thorny issue of multiqueue and os-vif, if you have a few seconds. | |