| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-12 | |||
| 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. | |
| 14:28:02 | artom | <vcpu cpuset=> or <cputune> ? | |
| 14:28:07 | sean-k-mooney | ill kick of 3 runs 1 with vcpu pin set 1 with onlyv cpu_dedicated_set and one with cpu_dedicated_set and cpu_shared_set | |
| 14:28:08 | stephenfin | artom: The same thing that was used for pinning with 'hw:cpu_policy' | |
| 14:28:17 | dansmith | sean-k-mooney: sounds good | |
| 14:28:22 | stephenfin | none of the libvirt XML stuff changes. This is all higher level accounting stuff | |
| 14:28:39 | dansmith | stephenfin: he knows, he's asking from a where-can-we-test perspective I think | |
| 14:29:01 | sean-k-mooney | FN is currenly offline since donnyd is doing a router upgrde so ill use vexhost instead for now | |
| 14:29:04 | stephenfin | Yeah, I get that. The answer is the same place we can test 'hw:cpu_policy=dedicated' currently | |
| 14:29:15 | artom | stephenfin, well I was asking because the allocation-styl <vcpu> pinning is what's done if the instance doens't have a NUMA topology and vcpu_pin_set is set (we talked about this, remember?) | |
| 14:29:16 | donnyd | I am ready to bring FN back online | |
| 14:29:19 | dansmith | stephenfin: unless one knows where that is... | |
| 14:29:21 | artom | stephenfin, and *that* can be tested in the gate | |
| 14:29:39 | artom | stephenfin, but from what you're saying that's not what your series uses | |
| 14:29:42 | sean-k-mooney | donnyd: well either works for this test i just need nested virt | |
| 14:29:52 | stephenfin | artom: yeah, no, the instance will have a NUMA topology because of the pinning | |