| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-12 | |||
| 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 | artom | Oh, hah, ignore me then :P | |
| 14:25:05 | dansmith | artom: but in general it's single node in-place | |
| 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 | mriedem | my wifi dropped (power outage) - talking about PCPU CI testing? | |
| 14:26:03 | sean-k-mooney | ok so tempest full single node with pinned flavor | |
| 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 | 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:26:24 | dansmith | mriedem: yes | |
| 14:27:01 | stephenfin | artom: I could point run whitebox locally? | |
| 14:27:01 | mriedem | stephenfin: alex_xu: have you done functional testing with the PCPU series where things aren't stubbed out? | |
| 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 | |
| 14:30:08 | sean-k-mooney | but i do need to go write a patch to add a lable that will use all the nested virt provder rater then just one specifically | |
| 14:31:02 | donnyd | sean-k-mooney: I think maybe vexxhost can also run this job. I don't want to speak on behalf of mnaser | |
| 14:31:19 | dansmith | donnyd: I think he's said several times that it can :) | |
| 14:31:30 | mnaser | yes should be ok | |
| 14:32:45 | donnyd | mnaser: do you have a flavor already built? | |
| 14:32:54 | sean-k-mooney | ill do all the nodepool lable stuff next week to make this more resiliant | |
| 14:33:02 | donnyd | kk sean-k-mooney | |
| 14:33:04 | sean-k-mooney | donnyd: this does not need the multi numa node stuff | |
| 14:33:13 | sean-k-mooney | just a single numa node is fine | |
| 14:33:19 | donnyd | oh just nested virt | |
| 14:33:24 | sean-k-mooney | yep | |
| 14:33:35 | sean-k-mooney | we just want to test pinning | |
| 14:33:44 | sean-k-mooney | since that is what we are chaning | |
| 14:34:12 | sean-k-mooney | once artoms stuff is actully merged i can retarget the multi numa job to also test stephens code | |
| 14:34:19 | sean-k-mooney | and get test coverage for both | |
| 14:34:27 | dansmith | migration with pinning "works" today but just blind copies everything to the other side, right? | |
| 14:34:35 | sean-k-mooney | ya | |
| 14:34:50 | dansmith | so these tests should also support migration but with smarts yeah? | |
| 14:35:16 | sean-k-mooney | i can run the migration tests if you like | |
| 14:35:22 | dansmith | yes, definitely | |
| 14:35:32 | sean-k-mooney | but it will do the wrong thing until artoms code lands | |
| 14:35:37 | mnaser | no i didn't get a chance to setup the flavor because it didn't seem pressing at the time :) | |
| 14:35:41 | dansmith | we need to at least make sure we don't regress the stupid behavior | |
| 14:35:41 | mnaser | ill wait until "we need it" | |
| 14:35:41 | sean-k-mooney | but if i use concurancy 1 it wont break anything | |
| 14:35:52 | dansmith | sean-k-mooney: or depends-on artoms? | |
| 14:36:08 | sean-k-mooney | im not sure if there will be a merge conflict | |
| 14:36:11 | sean-k-mooney | ill test that locally | |
| 14:36:15 | dansmith | uh | |
| 14:36:19 | openstackgerrit | Martin Midolesov proposed openstack/nova master: Implementing graceful shutdown. https://review.opendev.org/666245 | |
| 14:36:24 | dansmith | well, if there is we should rebase the pcpu stuff now, right? | |
| 14:36:35 | sean-k-mooney | am i guess so | |
| 14:36:50 | dansmith | maybe check locally first | |
| 14:36:55 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Support migrating SRIOV port with bandwidth https://review.opendev.org/676980 | |
| 14:36:55 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Allow migrating server with port resource request https://review.opendev.org/671497 | |
| 14:36:56 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Allow resizing server with port resource request https://review.opendev.org/679019 | |
| 14:36:56 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Extract pf$N literals as constants from func test https://review.opendev.org/680991 | |
| 14:36:57 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Improve dest service level func tests https://review.opendev.org/680998 | |
| 14:36:58 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Follow up for Ib50b6b02208f5bd2972de8a6f8f685c19745514c https://review.opendev.org/681490 | |
| 14:36:58 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Skip querying resource request in revert_resize if no qos port https://review.opendev.org/681513 | |
| 14:40:17 | sean-k-mooney | dansmith: artoms funtional tests still ned to be rebased but if i merge the cpu series with artoms serise without that it works locally | |
| 14:40:28 | sean-k-mooney | so ill do that quickly | |
| 14:40:33 | dansmith | sean-k-mooney: ack | |
| 14:40:53 | sean-k-mooney | the functionla patch we are leaving to not need to rebase all the rest | |
| 14:40:55 | dansmith | sean-k-mooney: that means you can depends-on it in your gate jobs yeah? or are you going to rebase all of pcpu and push it up? | |
| 14:41:04 | sean-k-mooney | so that will be rebased when the stuff is merged | |
| 14:41:16 | mriedem | gibi: bauzas: melwitt: i'm +2 up the bw provider migrate/resize series now https://review.opendev.org/#/q/topic:bp/support-move-ops-with-qos-ports+status:open | |
| 14:41:23 | mriedem | just a few changes need a +W but they aren't too hard | |
| 14:41:39 | sean-k-mooney | ya i just need to depnd on the second form last patch in artoms serie | |