| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-09-02 | |||
| 13:51:35 | bauzas | gibi: sean-k-mooney: /me needs help of a network specialist | |
| 13:52:44 | gibi | bauzas: I'm not sure I can help but ask :) | |
| 13:53:14 | bauzas | gibi: for instance create, we're passing requested_networks here https://github.com/openstack/nova/blob/b5d48043466b53fbdfe7b93c2e4efd449904e593/nova/compute/api.py#L954 | |
| 13:53:37 | bauzas | it's a NetworkRequestList object | |
| 13:54:06 | sean-k-mooney | :) | |
| 13:54:13 | bauzas | https://github.com/openstack/nova/blob/b5d48043466b53fbdfe7b93c2e4efd449904e593/nova/objects/network_request.py#L30 | |
| 13:54:46 | bauzas | so I can try to add a new field in some object that would be NetworkRequestList | |
| 13:54:47 | sean-k-mooney | stephenfin: our you could just add a microverion for the api removal too | |
| 13:55:02 | bauzas | sean-k-mooney: gibi: for example, directly the RequestSpec | |
| 13:55:03 | stephenfin | sean-k-mooney: it would be no-op though | |
| 13:55:22 | bauzas | sean-k-mooney: gibi: but if so, I need to use the same for the other move operations | |
| 13:55:24 | sean-k-mooney | well no after the version you would get 404 for the apis | |
| 13:55:38 | sean-k-mooney | stephenfin: ill take a look at your patch after bauzas thing | |
| 13:55:45 | stephenfin | right, but before the version you'd get nothing too | |
| 13:55:48 | bauzas | sean-k-mooney: gibi: but then, we no longer have NetworkRequests, just VIF objects | |
| 13:55:53 | stephenfin | since XenAPI is gone and those things only worked with XenAPI | |
| 13:56:16 | sean-k-mooney | stephenfin: oh i guess ya | |
| 13:56:17 | gibi | bauzas: yeah, so for boot you have network request for move you have either the cache or you can ask neutron for the bound ports of the instance | |
| 13:56:19 | bauzas | sean-k-mooney: gibi: so I wonder if I can create a new NetworkRequest object by using a VIF object | |
| 13:56:40 | gmann | stephenfin: ack, I will check in afternoon | |
| 13:56:53 | bauzas | sean-k-mooney: gibi: like we do in https://github.com/openstack/nova/blob/b5d48043466b53fbdfe7b93c2e4efd449904e593/nova/objects/request_spec.py#L547 | |
| 13:57:24 | sean-k-mooney | the vifs would have everything expction the pci_request_id i think | |
| 13:57:26 | bauzas | sean-k-mooney: gibi: tbc, what's the difference between a VIF object and a NetworkRequest one | |
| 13:58:03 | bauzas | sean-k-mooney: right, see https://github.com/openstack/nova/blob/b5d48043466b53fbdfe7b93c2e4efd449904e593/nova/network/neutron.py#L3064-L3076 | |
| 13:58:14 | sean-k-mooney | no tags or pci requests https://github.com/openstack/nova/blob/master/nova/network/model.py#L380-L404 | |
| 13:58:17 | gibi | I never tried to diff them, but I honeslty affraid of cached data as it might be stale | |
| 13:58:24 | sean-k-mooney | but it will have the network id and port id | |
| 13:59:08 | gibi | I might try to recreate the network request from neutron | |
| 13:59:21 | bauzas | gibi: do we persist it ? | |
| 13:59:26 | sean-k-mooney | bauzas VIF object are constructed form the info we get back form neutron | |
| 13:59:46 | sean-k-mooney | so they dont exist untill that point | |
| 13:59:57 | sean-k-mooney | the newtork request obejct are created in the api | |
| 14:00:04 | sean-k-mooney | based on the inital boot request | |
| 14:00:13 | gibi | bauzas: I think we persist the info_cache but I can be mistaken | |
| 14:00:21 | sean-k-mooney | yes | |
| 14:00:30 | sean-k-mooney | they are only persited in the info cache | |
| 14:00:39 | sean-k-mooney | they are also not ovo by the way | |
| 14:00:48 | bauzas | okay, I think we just need network_id | |
| 14:01:02 | bauzas | so this should work | |
| 14:01:13 | sean-k-mooney | yep so the VIF has a network subobject | |
| 14:01:19 | bauzas | ie. having a nested object be NetworkRequestList | |
| 14:01:25 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/network/model.py#L332 | |
| 14:01:34 | sean-k-mooney | which has the network id | |
| 14:01:58 | sean-k-mooney | bauzas: but just to be clear this will only work for migrations | |
| 14:02:02 | bauzas | and when moving, valuing this field like we do for https://github.com/openstack/nova/blob/master/nova/objects/request_spec.py#L538 by using the VIFs objects from instance info cache | |
| 14:02:12 | sean-k-mooney | it will likely not work for new spawns | |
| 14:02:28 | bauzas | sean-k-mooney: yeah that works, because we directly have the NetworkRequest objects when spawning | |
| 14:02:38 | sean-k-mooney | for new spawns we dont populate the info cache untill the compute node | |
| 14:02:46 | bauzas | yup, that's not a problem | |
| 14:02:52 | sean-k-mooney | ok | |
| 14:03:02 | bauzas | okay, I can try to provide a new revision today then | |
| 14:03:04 | bauzas | thanks | |
| 14:03:22 | gibi | I'm OK recovering the network_id from the cache and then populate network metadata based on that | |
| 14:04:02 | sean-k-mooney | you will proably want to add a function on the network_metadata object to do that | |
| 14:04:21 | bauzas | sean-k-mooney: I don't want to modify the network_medata object | |
| 14:04:32 | bauzas | just the requestspec object or the destination one | |
| 14:04:41 | sean-k-mooney | well you could put it in the request_sep too | |
| 14:04:48 | bauzas | yup, either | |
| 14:04:49 | sean-k-mooney | which ever object your adding the filed too | |
| 14:05:02 | sean-k-mooney | just have a helper function to populated it | |
| 14:05:42 | sean-k-mooney | basically i would like that fucntion to be testable on its own is all im really asking for | |
| 14:05:51 | sean-k-mooney | so we dont have to do complicated mocking in unit tests | |
| 14:14:12 | openstackgerrit | Merged openstack/nova master: Provider Config File: Coding style and test cases improvement https://review.opendev.org/748939 | |
| 14:40:14 | lyarwood | stephenfin: https://review.opendev.org/#/c/639934 LGTM, asked a quick question wrt to actual gate testing, I assume this isn't something we could wire up right now correct? | |
| 14:45:57 | stephenfin | looking | |
| 14:53:49 | sean-k-mooney | lyarwood: vtpm can be tested in the gate | |
| 14:54:21 | sean-k-mooney | we just need tempest tests with a new compute feature flag | |
| 14:54:45 | sean-k-mooney | to contol running them then we need to update devstack to install teh swtpm software and configure it | |
| 14:55:11 | sean-k-mooney | so it could be tested but we would need to do the automation | |
| 14:55:29 | sean-k-mooney | maybe this is somethign we can work with our qe folks to do | |
| 14:56:10 | sean-k-mooney | e.g. the tempest tests | |
| 14:56:53 | sean-k-mooney | extenting devstack is really just adding a new flag and apt/dnf instaling the package | |
| 14:56:53 | lyarwood | sean-k-mooney: wouldn't we need the clouds we are using to have vTPM enabled instances for us to passthrough? | |
| 14:57:01 | lyarwood | sean-k-mooney: or is it fully emulated | |
| 14:57:01 | sean-k-mooney | no | |
| 14:57:07 | sean-k-mooney | this is fully emulated | |
| 14:57:23 | lyarwood | gah sorry I got confused reading the libvirt docs | |
| 14:57:31 | openstackgerrit | Akhil Gudise proposed openstack/nova master: Introduced a service UP check for host to the Rebuild path https://review.opendev.org/749531 | |
| 14:58:05 | lyarwood | if it's fully emulated then it would've been nice to have a WIP posted already for this tbh | |
| 14:58:49 | sean-k-mooney | i could wip up a temp patch but we dont normally require tempest for a featre to merge | |
| 14:59:14 | sean-k-mooney | e.g. jsut chnage the tempest flaovrs and hardcode the tpm extra specs | |
| 14:59:22 | sean-k-mooney | and manulaly install swtpm | |
| 14:59:31 | lyarwood | sean-k-mooney: we have required tempest changes in the past FWIW | |
| 14:59:44 | sean-k-mooney | not that im aware of | |
| 14:59:59 | stephenfin | swtpm isn't packaged on Ubuntu yet :( | |
| 14:59:59 | sean-k-mooney | we have said they shoudl be added but we have merged the code before hand | |
| 15:00:03 | lyarwood | sean-k-mooney: I've had encrypted volume and stable rescue stuff held up in the past | |
| 15:00:08 | stephenfin | so we'd need to enable some PPAs | |
| 15:00:13 | sean-k-mooney | really | |
| 15:00:18 | sean-k-mooney | stephenfin: ya that is easy to do | |
| 15:00:18 | lyarwood | stephenfin: well we also have Fedora ;) | |
| 15:01:05 | sean-k-mooney | any way moving on form that crazy fedora idea :P | |
| 15:01:25 | sean-k-mooney | am do we want a quick DNM patch to hack in a full tempest run | |
| 15:01:44 | stephenfin | also, the version of QEMU and libvirt on Ubuntu 18.04 is too old | |
| 15:01:49 | sean-k-mooney | like we have done for numa before | |
| 15:01:56 | stephenfin | I had to use Fedora 31 for testing this locally | |
| 15:01:57 | lyarwood | *cough* Fedora *cough* | |
| 15:02:00 | sean-k-mooney | stephenfin: we are ment to be on ubuntu 20.04 | |
| 15:02:03 | sean-k-mooney | before m3 | |
| 15:02:11 | lyarwood | yeah good luck with that | |