| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-12 | |||
| 13:58:39 | bauzas | stephenfin: can you please tell me why we need this https://review.opendev.org/#/c/681750/1/nova/tests/unit/virt/libvirt/fake_imagebackend.py ? | |
| 13:58:52 | mriedem | i hope there is going to be some "so you want to use PCPUs" admin doc at some point b/c there are a ton of moving parts | |
| 13:59:17 | bauzas | mriedem: I feel there are some docs that absolutely need to be written | |
| 13:59:20 | stephenfin | bauzas: There's a check deep in the libvirt code for that. If it's not done, it complains with "function doesn't have attribute SUPPORTS_CLONE" | |
| 13:59:33 | bauzas | mriedem: in particular given the upgrade plan we took a while to agree this morning | |
| 13:59:50 | stephenfin | bauzas: I'm not the only one who found that. This is from the vPMEM series https://review.opendev.org/#/c/678470/35/nova/tests/unit/virt/libvirt/fake_imagebackend.py | |
| 13:59:51 | mriedem | stephenfin: there should probably be a comment on that in the fake imagebackend code then | |
| 14:00:02 | bauzas | stephenfin: what mriedem said | |
| 14:00:15 | bauzas | because I have no idea why you need this | |
| 14:00:23 | mriedem | pretty gross that the virt agnostic image backend fixture has to have libvirt specific stuff in it | |
| 14:00:56 | mriedem | bauzas: stephenfin loves to doc so i'm sure he doesn't have a problem documenting all the things | |
| 14:01:22 | bauzas | mriedem: the upgrade strategy is a bit tricky, I'm just saying we need to carefully doc it | |
| 14:01:35 | bauzas | based on the fact we'll provide some options | |
| 14:01:38 | stephenfin | mriedem: It's a libvirt-specific image backend fixture - look at the filename | |
| 14:01:51 | stephenfin | it's for mocking out nova/virt/libvirt/imagebackend.py | |
| 14:02:56 | mriedem | stephenfin: you're right, sorry - i was thinking of https://review.opendev.org/#/c/678470/35/nova/tests/unit/image/fake.py | |
| 14:03:36 | stephenfin | all g | |
| 14:03:43 | stephenfin | I wonder what the comment should be though | |
| 14:04:10 | stephenfin | I mean, it's an attribute of the Image base class in nova/virt/libvirt/imagebackend.py | |
| 14:04:26 | stephenfin | and this function is a stub for that class (or some subclass) | |
| 14:04:50 | stephenfin | so it's not really doing anything special but rather just ensuring the stub looks like the thing it's stubbing | |
| 14:05:22 | mriedem | # Set the SUPPORTS_CLONE member variable to satisfy the Image base class. | |
| 14:08:11 | stephenfin | Sounds good. Done | |
| 14:08:15 | openstackgerrit | Stephen Finucane proposed openstack/nova master: tests: Additional functional tests for pinned instances https://review.opendev.org/681750 | |
| 14:08:16 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Add support for translating CPU policy extra specs, image meta https://review.opendev.org/671801 | |
| 14:08:16 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Include both VCPU and PCPU in core quota count https://review.opendev.org/681374 | |
| 14:08:17 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Mock 'libvirt_utils.file_open' properly https://review.opendev.org/681061 | |
| 14:08:17 | openstackgerrit | Stephen Finucane proposed openstack/nova master: fakelibvirt: Make 'Connection.getHostname' unique https://review.opendev.org/681060 | |
| 14:08:18 | openstackgerrit | Stephen Finucane proposed openstack/nova master: trivial: Remove single-use classmethod https://review.opendev.org/681751 | |
| 14:08:18 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Add reshaper for PCPU https://review.opendev.org/674895 | |
| 14:09:10 | openstackgerrit | Stephen Finucane proposed openstack/nova master: trivial: Remove single-use classmethod https://review.opendev.org/681751 | |
| 14:13:33 | dansmith | stephenfin: what job logs can I look at to see this running? | |
| 14:14:29 | stephenfin | dansmith: Look at the functional logs for https://review.opendev.org/#/c/671801 | |
| 14:14:41 | dansmith | no I mean a devstack/tempest job | |
| 14:16:17 | stephenfin | None. The Intel NFV CI has been missing for quite some time. It's been alex_xu, sean-k-mooney, Bhagyashri Shewale (forgot his IRC nick) and I testing it locally | |
| 14:16:37 | dansmith | stephenfin: is there some reason this has to be tested in special ci? | |
| 14:16:51 | sean-k-mooney | yes it need nested virt | |
| 14:16:52 | stephenfin | Pinned CPUs. That needs nested virt | |
| 14:16:58 | stephenfin | which we can't rely on | |
| 14:17:00 | sean-k-mooney | but i can test it in FN | |
| 14:17:06 | dansmith | we can't get a one-off? | |
| 14:17:14 | dansmith | sean-k-mooney: that would be good | |
| 14:17:22 | artom | stephenfin, wait, I thought this used the <vcpus> style pinning, no? | |
| 14:17:29 | artom | Which *does* work in the vanilla gate | |
| 14:17:42 | dansmith | I'm shocked that artom and sean-k-mooney were able to get numa live migration tested for us, so surely this is possible | |
| 14:18:07 | sean-k-mooney | that was also testing pinning with the resize flavors | |
| 14:18:09 | sean-k-mooney | so yes | |
| 14:18:23 | artom | dansmith, let's be honest, *sean-k-mooney* was able to get NUMA live migration tested | |
| 14:18:37 | dansmith | artom: I just meant that effort, but sure | |
| 14:18:38 | stephenfin | sean-k-mooney: can we just point the same job at the top-most change of this so? | |
| 14:18:51 | sean-k-mooney | we can also technical test non numa stuff in vexhost and limestone | |
| 14:19:13 | sean-k-mooney | stephenfin: yes but ill create a second patch | |
| 14:19:14 | dansmith | I'm disappointed that nobody has asked this question yet :/ | |
| 14:19:20 | sean-k-mooney | i want to actully merge that job | |
| 14:20:28 | stephenfin | between manual tests and the functional tests, I figure our coverage is pretty much spot on as-is | |
| 14:20:33 | dansmith | stephenfin: what testing are you doing locally? Just hand booting some things or running tempest? | |
| 14:20:48 | artom | dansmith, presumably the crucial thing would be testing the upgrade path - so something grenade-y? | |
| 14:20:50 | stephenfin | dansmith: https://etherpad.openstack.org/p/nova-cpu-resources | |
| 14:21:27 | stephenfin | alex_xu has his own set of tests that he's been working towards too | |
| 14:21:28 | sean-k-mooney | what do people want me to actully test for this in the ci job? | |
| 14:21:36 | dansmith | artom: I'm definitely concerned about that yeah, but more concerned about at least seeing a tempest run first | |
| 14:21:52 | sean-k-mooney | for the live migration job i ran the live migration test shoudl i jsut run the server and network baskic op | |
| 14:21:57 | dansmith | stephenfin: that's cool, but it's far from comprehensive | |
| 14:22:09 | alex_xu | more on upgrade case, one node old, one node new, then boot, resize between nodes | |
| 14:22:20 | sean-k-mooney | also do you want a singel node test or multi | |
| 14:22:35 | dansmith | sean-k-mooney: if you're going to run the grenade job, multi would be good | |
| 14:23:07 | sean-k-mooney | im not sure how easy grenate will be. i could try the non legacy grenade job however | |
| 14:23:40 | sean-k-mooney | ok i can give grenade a try but ill do a non grenade run first | |
| 14:23:46 | artom | Hrm, so actually grenade is not what I meant by upgrade | |
| 14:23:58 | artom | I mean it's good too, but... | |
| 14:24:16 | artom | I'd be most concerned about the in-place upgrade scenario | |
| 14:24:27 | dansmith | artom: how is that not grenade? | |
| 14:24:35 | artom | dansmith, wait, does grenade do that? | |
| 14:24:44 | sean-k-mooney | thats all greande does | |
| 14:24:45 | artom | I thought it just deployed a mix of old and new computes | |
| 14:24:48 | dansmith | artom: that is all it does | |
| 14:24:51 | artom | It upgrades in place? | |
| 14:24:55 | sean-k-mooney | yes | |
| 14:24:56 | dansmith | artom: it can leave one back | |
| 14:25:05 | dansmith | artom: but in general it's single node in-place | |
| 14:25:05 | artom | Oh, hah, ignore me then :P | |
| 14:25:32 | sean-k-mooney | if its multi node it does the contoler first then you do the live migrate back and for test | |
| 14:25:33 | mriedem | the grenade multinode jobs leave one nova-compute back | |
| 14:25:34 | artom | Oh, and the multinode version of it does the live migration back and forth business | |
| 14:25:42 | dansmith | sean-k-mooney: I think a full basic tempest run would be good just to make sure we're good on things like resizes, etc | |
| 14:25:44 | mriedem | artom: yeah | |
| 14:26:03 | sean-k-mooney | ok so tempest full single node with pinned flavor | |
| 14:26:03 | mriedem | my wifi dropped (power outage) - talking about PCPU CI testing? | |
| 14:26:17 | dansmith | I'm concerned that maybe nobody has even run tempest against this yet to the point that there may be some gotchas we don't know about such that it can't run :/ | |
| 14:26:24 | dansmith | mriedem: yes | |
| 14:26:24 | artom | So actually wouldn't we be able to just resurect https://review.opendev.org/#/c/680806/ and make it depend on stephenfin's series? | |
| 14:27:01 | mriedem | stephenfin: alex_xu: have you done functional testing with the PCPU series where things aren't stubbed out? | |
| 14:27:01 | stephenfin | artom: I could point run whitebox locally? | |
| 14:27:17 | artom | stephenfin, whitebox doesn't have any code to test your stuff | |
| 14:27:18 | sean-k-mooney | dansmith: well tempest has run with out pinning so if i do a run with only pinning that covers it right | |
| 14:27:20 | dansmith | mriedem: they have an etherpad of hand-run test cases | |
| 14:27:38 | alex_xu | mriedem: I done manual test with upgrade case | |
| 14:27:42 | dansmith | sean-k-mooney: yeah, isn't that what we're talking about here? | |
| 14:27:50 | artom | stephenfin, but... in your series, for instances using the PCPU resource class, what's the XML that pins them? | |
| 14:27:51 | stephenfin | artom: It tests that we can boot pinned instances, resize them, etc. | |