| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-12-02 | |||
| 18:04:06 | openstack | Launchpad bug 1289064 in OpenStack Compute (nova) "live migration of instance should claim resources on target compute node" [Medium,In progress] - Assigned to Artom Lifshitz (notartom) | |
| 18:04:06 | sean-k-mooney | artom: melwitt so we might just be able to close https://bugs.launchpad.net/nova/+bug/1289064 | |
| 18:04:28 | eandersson | https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L2075 <-- eventlet.Timeout (based on BaseException, not Exception) may be raised here causing an UnboundError. | |
| 18:05:32 | mriedem | eandersson: nope | |
| 18:06:03 | melwitt | sean-k-mooney: if there's not anything more to do there, I'd think it would be nice to close it | |
| 18:07:10 | sean-k-mooney | well there are still cases where live migration is not supported but on master i think we account for all resouces correctly in the cases where live migration is supported | |
| 18:07:17 | mriedem | eandersson: open a bug | |
| 18:07:49 | artom | sean-k-mooney, melwitt, so.... fix release 'Train'? | |
| 18:08:17 | dansmith | efried: Sundar: I was on a call during your discussion, but...we're all good now? | |
| 18:08:20 | sean-k-mooney | artom: ya i think so | |
| 18:09:06 | melwitt | yeah, I can't remember how/if there's a way to mark it as fixed in the past. but I don't think that matters too much | |
| 18:09:25 | artom | Done. | |
| 18:09:29 | sean-k-mooney | you can add the sepcific release series to the bug | |
| 18:09:41 | sean-k-mooney | i left a comment in the bug too | |
| 18:10:12 | openstack | Launchpad bug 1854848 in OpenStack Compute (nova) "build_and_run_instance can error out with an UnboundException" [Undecided,New] | |
| 18:10:12 | eandersson | mriedem https://bugs.launchpad.net/nova/+bug/1854848 | |
| 18:10:28 | Sundar | efried: I think so, if you and all are ok with whatever I said above -- squishing the patches, etc. ignoring 422 alone seems fine. if n-api is unreachable or times out, that will still be an error that fails the binding. | |
| 18:10:30 | sean-k-mooney | artom: added train | |
| 18:10:39 | eandersson | It's a minor issue, but caused VMs to get stuck in BUILD... fyi was caused by selinux not being configured properly. | |
| 18:11:04 | sean-k-mooney | artom: melwitt there is a "Target to series" button you can use | |
| 18:11:17 | sean-k-mooney | you need to be in the nova bug team on LP to see/use it | |
| 18:12:09 | melwitt | yeah, I have that, but I don't think that will stop it from saying "released in <U version number>" whenever it's released next | |
| 18:12:58 | melwitt | it'll still count it as landing "today" first and then "backported" to train. I don't think it matters, just that's what the automation is gonna do when it comments later | |
| 18:13:56 | sean-k-mooney | ya proably | |
| 18:14:39 | sean-k-mooney | i dont think we have automation tieded to that out side of the completed specs thing but that uses blueprints not bugs | |
| 18:16:11 | sean-k-mooney | artom: if you are triaging nova bugs upstream you should join https://launchpad.net/~nova-bugs its an open team so you will be automatically approved | |
| 18:16:32 | artom | sean-k-mooney, can't say I'm triaging dilligently | |
| 18:17:25 | sean-k-mooney | well you know where to find it if you change your mind | |
| 18:17:52 | melwitt | sean-k-mooney: I mean the thing that will make a comment on the bug that says "this bug was fixed in version x.x.x.x" that will be technically wrong because it's gonna say a U version. again, I don't think it matters, just that's what it's going to say on the comment | |
| 18:18:12 | sean-k-mooney | 00. | |
| 18:18:14 | sean-k-mooney | 00.1 | |
| 18:18:20 | sean-k-mooney | droped phone | |
| 18:18:42 | sean-k-mooney | am isnt that done by the release tooling | |
| 18:18:48 | sean-k-mooney | not launchpad | |
| 18:19:15 | melwitt | it is yeah | |
| 18:19:28 | sean-k-mooney | but ya i guess in this case its not going to be set since artoms change did not have closes bug | |
| 18:20:00 | sean-k-mooney | anyway it should be fine | |
| 18:20:17 | melwitt | I don't think it matters, I think it just does a sweep through things that are Fix Released and makes a comment with the fixed in version | |
| 18:27:47 | efried | dansmith: Yes, thanks. | |
| 18:30:16 | dansmith | efried: so there'll need to be a change to cyborg for the 422 thing presumably | |
| 18:30:24 | efried | yes | |
| 18:31:02 | dansmith | efried: Sundar: is there a testing patch somewhere in the series that wires this all up with a fake cyborg driver? | |
| 18:31:22 | dansmith | I assume that would be the one that needs to depends-on that cyborg change | |
| 18:31:26 | efried | the CI job is working last I checked | |
| 18:31:58 | sean-k-mooney | there is a patch to add a tempest job againd nova nad i think the job is now running on all cyborg patches | |
| 18:31:59 | dansmith | there are a lot of patches that have various confused histories | |
| 18:32:05 | efried | dansmith: https://review.opendev.org/#/c/670999/20 | |
| 18:32:10 | efried | passing atm | |
| 18:32:11 | dansmith | ack just found that | |
| 18:32:34 | sean-k-mooney | same was going to link it | |
| 18:33:15 | efried | there was a time when I looked and it wasn't doing anything, but I thought the last time I checked it was actually running through the spawn flow with a real (pseudo) device | |
| 18:33:29 | sean-k-mooney | it is doing two things | |
| 18:33:31 | efried | still very basic though | |
| 18:33:35 | efried | green path only | |
| 18:33:51 | sean-k-mooney | its cratein a device profile and then a super minima test of booting a vm | |
| 18:33:55 | sean-k-mooney | althogh that one is not correct | |
| 18:34:09 | sean-k-mooney | its booting a vm but not waiting for ti to go active before deleting it | |
| 18:34:35 | sean-k-mooney | at least the last time i looked but everythin is in place to add proper lifecycle tests | |
| 18:34:37 | dansmith | seems like a lot of vm_state=error in the compute logs for that, I'll have to track it down closer to see if it's related | |
| 18:35:17 | sean-k-mooney | https://opendev.org/openstack/cyborg-tempest-plugin/src/branch/master/cyborg_tempest_plugin/tests/scenario/test_accelerator_basic_ops.py#L45-L60 | |
| 18:35:46 | dansmith | does that even wait for it to become running? | |
| 18:36:03 | sean-k-mooney | no which i mentioned before | |
| 18:36:22 | sean-k-mooney | to the cyborg folks | |
| 18:36:32 | sean-k-mooney | create server does https://opendev.org/openstack/cyborg-tempest-plugin/src/branch/master/cyborg_tempest_plugin/tests/scenario/manager.py#L245-L257 | |
| 18:36:33 | dansmith | heh okay | |
| 18:36:38 | dansmith | oh okay | |
| 18:36:47 | dansmith | also, the name of the test makes it hard to track down those instances in the logs | |
| 18:36:57 | dansmith | would be better if it was called test_server_ops_with_accel or something | |
| 18:37:41 | sean-k-mooney | ya with that said its an easy change as is extenidn it to do more really tests | |
| 18:37:55 | Sundar | sean-k-mooney: The tempest test waits till the server becomes active: https://review.opendev.org/#/c/667231/11/cyborg_tempest_plugin/tests/scenario/manager.py@155 | |
| 18:39:08 | sean-k-mooney | oh you are using the common tempest function ok | |
| 18:39:08 | dansmith | I don't see that the cyborg instance ever made it to the compute node | |
| 18:40:06 | Sundar | dansmith: The tempest CI test in cyborg-tempest-plugin is called test_server_basic_ops '' https://review.opendev.org/#/c/667231/11/cyborg_tempest_plugin/tests/scenario/test_accelerator_basic_ops.py@45 | |
| 18:40:24 | dansmith | Sundar: right, which makes it hard to distinguish from the other test_server_basic_ops | |
| 18:40:41 | dansmith | I don't see it actually running though: https://8664d62e69400bd89796-9cb1d5e035819d8d5535734f80756cd4.ssl.cf1.rackcdn.com/670999/20/check/tempest-integrated-compute/cdfc846/testr_results.html.gz | |
| 18:40:48 | sean-k-mooney | Sundar: that is an existing class name in tempest | |
| 18:41:00 | dansmith | oh wait, that's the wrong log, ignore me | |
| 18:41:46 | sean-k-mooney | although the module path should be different | |
| 18:41:55 | Sundar | If you just want to mention 'accel' somewhere in the name, that's not a problem. Will do. | |
| 18:42:06 | dansmith | sean-k-mooney: right but the test name is what drives the tempest tenant name I think | |
| 18:42:13 | sean-k-mooney | https://2371b0492dbe3a0c56c0-5469ab4f5c2741453cb8b95135b2c449.ssl.cf2.rackcdn.com/670999/20/check/cyborg-tempest/2124885/testr_results.html.gz | |
| 18:42:19 | sean-k-mooney | that is the result you were looking for | |
| 18:42:28 | dansmith | but they're hardcoding the server name, which helps | |
| 18:42:29 | dansmith | yeah I know | |
| 18:42:58 | dansmith | so for this fake test, we don't actually provide any device to libvirt to attach to the guest right: | |
| 18:43:00 | dansmith | ? | |
| 18:43:17 | Sundar | That's right | |
| 18:43:21 | sean-k-mooney | correct | |
| 18:43:36 | sean-k-mooney | the arq has type fake and its ignored | |
| 18:43:43 | Sundar | The path till creating/binding.getting ARQs is the same as for a real driver | |
| 18:43:49 | dansmith | will there be a real job running on intel ci or something that can actually do this? | |
| 18:44:03 | dansmith | Sundar: sure, it just doesn't cover actually producing a device and getting libvirt to attach it | |
| 18:44:09 | Sundar | dansmith: Yes, we are planning a 3rd party CI for Intel FPGAs | |
| 18:44:22 | sean-k-mooney | we could maybe use some other virtual device for testing in a more robust way too | |
| 18:45:14 | dansmith | sean-k-mooney: yeah I was going to ask if we could pass some harmless pci device through, but wasn't sure if we can do that in the gate without nested | |
| 18:45:19 | Sundar | sean-k-mooney: We have plans to enhance the fake driver to simulate programming -- it will just respons to the programming API within Cyborg with a success/failure | |
| 18:45:35 | sean-k-mooney | dansmith: i was thinking of creating a file on disk and passing it to the guest | |
| 18:45:45 | dansmith | Sundar: yeah, that's good, I just want to see the actual "here's the pci device" stuff tested | |
| 18:45:48 | Sundar | That would cover more paths, including Glance interaction within Cyborg. But it would still not attach a PCI device to the VM | |
| 18:46:02 | dansmith | sean-k-mooney: how does a file on disk simulate a pci device/ | |