| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-09-02 | |||
| 12:13:15 | sean-k-mooney | songwenping_: i think that class path will only exist if you have mdevs allocated | |
| 12:13:38 | sean-k-mooney | songwenping_: but as i said you cant use ubuntu as a host os for nvida grid | |
| 12:14:03 | sean-k-mooney | i can be the guest os but nvidia does not make the host level driver availabel for ubuntu | |
| 12:17:07 | songwenping_ | sean-k-mooney: yeah, i have allocated mdevs and i reinstall vgpu-kvm package. | |
| 12:17:55 | sean-k-mooney | songwenping_: where did you get the package for ubuntu? | |
| 12:18:38 | songwenping_ | nvidia official website | |
| 12:18:49 | songwenping_ | NVIDIA-Linux-x86_64-440.107-vgpu-kvm.run | |
| 12:19:07 | sean-k-mooney | https://docs.nvidia.com/grid/10.0/product-support-matrix/index.html | |
| 12:19:19 | sean-k-mooney | according to that ubnuntu is not supported as a host os | |
| 12:20:05 | songwenping_ | the path is /sys/class/mdev_bus/0000\:af\:00.0/mdev_supported_types/ generate, but nothing in it.:( | |
| 12:20:42 | sean-k-mooney | your going to have to talk to nvidia about that | |
| 12:22:27 | sean-k-mooney | the offical nividia doc which was last update on the 21st of august says ubunut is not supported i think you install the ubunut guest driver on the host | |
| 12:22:28 | songwenping_ | sean-k-mooney, bauzas: thanks a lot. i'll try to use ubuntu guest. | |
| 12:22:57 | openstackgerrit | Yao wang proposed openstack/nova master: Use VIR_DOMAIN_XML_INACTIVE for detach volume https://review.opendev.org/749489 | |
| 12:36:59 | bauzas | songwenping__: FWIW, for nvidia specific issues like it, please look at their documentation for vGPUs https://docs.nvidia.com/grid/latest/grid-vgpu-user-guide/index.html#grid-vgpu-introduction | |
| 12:37:36 | bauzas | the openstack community is not an nvidia support team :p | |
| 12:46:04 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/queens: Add regression tests for bug #1889108 https://review.opendev.org/749232 | |
| 12:46:04 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/queens: compute: Don't delete the original attachment during pre LM rollback https://review.opendev.org/749233 | |
| 12:46:05 | openstack | bug 1889108 in OpenStack Compute (nova) train "failures during driver.pre_live_migration remove source attachments during rollback" [Undecided,In progress] https://launchpad.net/bugs/1889108 - Assigned to Lee Yarwood (lyarwood) | |
| 12:47:07 | stephenfin | jkulik: sure, done | |
| 13:46:04 | openstackgerrit | Stephen Finucane proposed openstack/nova master: WIP: Resolve issues with various HTTP status codes https://review.opendev.org/749505 | |
| 13:46:43 | stephenfin | gmann, sean-k-mooney, gibi: There's a potential solution to our "no microversion in Victoria" conundrum ^ If that's not completely bonkers, I could probably finish it today | |
| 13:47:02 | stephenfin | though, in fairness, it probably is completely bonkers :) | |
| 13:47:13 | gibi | stephenfin: ack, will look. | |
| 13:47:33 | stephenfin | fair fair | |
| 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 | |