| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-12 | |||
| 21:17:33 | mriedem | and i'm pretty sure the tempest tearDown waits for the servers to be gone, i.e. 404 from the API | |
| 21:18:10 | sean-k-mooney | the case weher we saw that errror the teardwon failed to delete before hiting the timeout | |
| 21:18:31 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Correctly handle non-CPU flag traits https://review.opendev.org/681932 | |
| 21:18:56 | stephenfin | mriedem, dansmith, efried: ^ | |
| 21:19:15 | mriedem | stephenfin: is that a master only regression? it should probably have a bug | |
| 21:19:23 | stephenfin | test is wrong - I rushed it | |
| 21:19:28 | stephenfin | I can do that | |
| 21:19:45 | mriedem | so only unit tests, no functional coverage | |
| 21:19:58 | sean-k-mooney | did that get intoduced with the sev stuff | |
| 21:20:02 | mriedem | this might be where i asked for a nova/tests/functional/regressions test case | |
| 21:20:18 | mriedem | code: do something wrong | |
| 21:20:25 | mriedem | unit test: assert the code did something wrong | |
| 21:23:20 | stephenfin | can someone give me an example of a non-CPU flag trait we support at the moment? | |
| 21:25:27 | mriedem | COMPUTE_SUPPORTS_MULTIATTACH | |
| 21:25:42 | sean-k-mooney | i was going to mention the once in my seriese that we punted... | |
| 21:25:47 | sean-k-mooney | ya that | |
| 21:26:07 | mriedem | so i bet we could recreate in devstack by just adding that to a tempest flavor yeah? | |
| 21:26:35 | sean-k-mooney | ya | |
| 21:27:01 | sean-k-mooney | you can do it the way im doing all the nfv/numa jobs | |
| 21:27:22 | mriedem | heh even just COMPUTE_ATTACH_INTERFACE | |
| 21:27:44 | stephenfin | mriedem: https://bugs.launchpad.net/nova/+bug/1843836 | |
| 21:27:45 | openstack | Launchpad bug 1843836 in OpenStack Compute (nova) "Failure to schedule if flavor contains non-CPU flag traits" [Undecided,New] | |
| 21:27:49 | sean-k-mooney | well all the compute capablity traits fall into that catagory right | |
| 21:28:16 | mriedem | stephenfin: yeah anything in here really https://github.com/openstack/nova/blob/master/nova/virt/driver.py#L102 | |
| 21:28:31 | efried | artom et al, numalm bottom failed l-c on subunit parser https://storage.bhs1.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_769/634827/60/check/openstack-tox-lower-constraints/7693dab/testr_results.html.gz | |
| 21:28:58 | artom | efried, ugh, recheck? | |
| 21:29:20 | artom | That's not a legit thing, right? | |
| 21:29:23 | efried | #2 failed functional on 6!=7 -- we fixed that mriedem right? Rebase? | |
| 21:29:33 | efried | artom: question whether to recheck or rebase | |
| 21:29:41 | efried | artom: you're way down the master branch | |
| 21:29:42 | mriedem | efried: gate should pick it up from master | |
| 21:29:54 | efried | you would think so mriedem, but it's possible this was queued from before that merged too. | |
| 21:29:59 | efried | https://ebfd4ec54dbc92b01f1e-dbc96e30a25abd79ad83d28f747c4e2b.ssl.cf2.rackcdn.com/635229/62/check/nova-tox-functional/a59c098/testr_results.html.gz | |
| 21:30:01 | artom | efried, yeah, that was intentional to make reviewing easier | |
| 21:30:03 | mriedem | the subunit to parser failure is when a test dumps too much shit to the logging output stream | |
| 21:30:04 | sean-k-mooney | efried: it will do a merge of the patch you see in gerrit and master | |
| 21:30:09 | mriedem | efried: yeah maybe | |
| 21:30:15 | mriedem | that claims one was in the gate b/c my fix was merged | |
| 21:30:25 | mriedem | *before | |
| 21:30:39 | efried | #3 hasn't failed yet, #4 is still queued | |
| 21:31:11 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Correctly handle non-CPU flag traits https://review.opendev.org/681932 | |
| 21:31:13 | efried | so the question is, do we recheck 1&2, hoping 3&4 pass, and save their place in the queue | |
| 21:31:13 | efried | or do we rebase, and lose 3&4's place in the queue | |
| 21:31:13 | sean-k-mooney | if we are going to rebase the LM series now is proably better then in a few hours | |
| 21:31:29 | efried | artom: your call | |
| 21:31:38 | stephenfin | mriedem: I'll whip up a functional test for that tomorrow. It's too late to face into that now | |
| 21:31:41 | mriedem | ha, got a node after 11 hours, then failed | |
| 21:31:51 | stephenfin | but unit test is fixed and I've linked the bug | |
| 21:31:55 | mriedem | stephenfin: sure, i was just going to push a simple devstack patch to show the failure | |
| 21:32:03 | artom | efried, does it really matter? I'm assuming if I rebase now, I'll get administrative +Ws | |
| 21:32:04 | efried | artom: first option we have to wait until gate posts actual failure, which will be a while. IMO second option would be best | |
| 21:32:14 | efried | artom: yes | |
| 21:32:15 | artom | It's not like we need this by tomorrow | |
| 21:32:40 | stephenfin | giant chain of patches | |
| 21:32:41 | stephenfin | wheee | |
| 21:32:44 | mriedem | artom: sorry but my +Ws on that series were only good through yesterday | |
| 21:32:44 | artom | It can wait the weekend or w/e, when the load on the gate isn't as high | |
| 21:32:51 | artom | mriedem, you sonnova | |
| 21:32:57 | mriedem | i thought you saw the disclaimer? | |
| 21:33:18 | sean-k-mooney | artom: we are better off just rebasing it now i think | |
| 21:33:30 | efried | artom: by rebasing now, you kick four patches out of the queue, leaving room for other things. | |
| 21:33:55 | sean-k-mooney | if we can line ups the LM serise then put PCPUs on top the vPMEM i think that is the best path forward | |
| 21:34:31 | stephenfin | sean-k-mooney: As things would have it, I've got a PCPUs on vPMEM rebase just waiting to go | |
| 21:35:11 | sean-k-mooney | stephenfin: then after artom pushs can you rebase on top? | |
| 21:35:21 | efried | don't do that ^ | |
| 21:35:21 | stephenfin | yarp | |
| 21:35:25 | efried | cause it'll kick vpmem out | |
| 21:35:25 | stephenfin | or not | |
| 21:35:30 | stephenfin | actually, yeah, no | |
| 21:35:40 | mriedem | are these all conflicting? | |
| 21:35:43 | efried | minorly | |
| 21:35:51 | stephenfin | PCPU doesn't conflict with LM | |
| 21:35:58 | efried | and I un-conflicted vpmem with lm | |
| 21:35:59 | mriedem | i really only care about numa lm | |
| 21:36:03 | efried | yeah we know | |
| 21:36:05 | artom | mriedem, <3 | |
| 21:36:14 | stephenfin | VPMEM conflicted with LM but efried fixed it | |
| 21:36:20 | mriedem | ...because it's been a thing people have wanted forever | |
| 21:36:23 | stephenfin | PCPU and VPMEM is a horror show | |
| 21:36:40 | sean-k-mooney | mriedem: sicne we intoduced numa in like juno | |
| 21:36:42 | artom | mriedem, and here I thought it was because of my pretty eyes | |
| 21:36:42 | stephenfin | in terms of number of merge conflicts, not complexity | |
| 21:36:54 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: New objects for NUMA live migration https://review.opendev.org/634827 | |
| 21:36:54 | artom | Incoming | |
| 21:36:54 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: LM: Use Claims to update numa-related XML on the source https://review.opendev.org/635229 | |
| 21:36:55 | mriedem | artom: you do have nice brown (?) eyes | |
| 21:36:55 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: NUMA live migration support https://review.opendev.org/634606 | |
| 21:36:55 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Deprecate CONF.workarounds.enable_numa_live_migration https://review.opendev.org/640021 | |
| 21:36:56 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Functional tests for NUMA live migration https://review.opendev.org/672595 | |
| 21:36:58 | mriedem | i got lost in them | |
| 21:37:09 | efried | hazel is my vote | |
| 21:37:18 | mriedem | +Wing | |
| 21:37:20 | stephenfin | I could have worked on k8s... | |
| 21:37:35 | sean-k-mooney | stephenfin: i hear you like yaml | |
| 21:37:45 | sean-k-mooney | stephenfin: becasue that is all k8s is as a user | |
| 21:38:45 | mriedem | soon we'll all only code in yaml | |
| 21:39:07 | efried | mriedem: "I'll push a devstack change to put a required trait that I know will be on all libvirt computes and that can show the failure for us quicker than writing some functional libvirt test." I assume this is a joke. | |
| 21:39:22 | mriedem | efried: nope | |
| 21:39:29 | mriedem | it's a 2 line change in devstack, | |
| 21:39:33 | mriedem | yes i know it will take awhile to get a node | |