| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-02-20 | |||
| 01:08:12 | opendevreview | Ghanshyam proposed openstack/nova master: Server actions APIs scoped to project scope https://review.opendev.org/c/openstack/nova/+/824358 | |
| 01:52:39 | opendevreview | Ghanshyam proposed openstack/nova master: Modify remaining APIs as per RBAC new guidelines https://review.opendev.org/c/openstack/nova/+/828994 | |
| 01:59:55 | opendevreview | Ghanshyam proposed openstack/nova master: Modify remaining APIs as per RBAC new guidelines https://review.opendev.org/c/openstack/nova/+/828994 | |
| 02:03:12 | opendevreview | Ghanshyam proposed openstack/nova master: Separate flavor extra specs policy for server APIs https://review.opendev.org/c/openstack/nova/+/829626 | |
| 02:05:47 | opendevreview | Ghanshyam proposed openstack/nova master: Separate flavor extra specs policy for server APIs https://review.opendev.org/c/openstack/nova/+/829626 | |
| 02:06:28 | opendevreview | Ghanshyam proposed openstack/nova master: Complete phase-1 of RBAC community-wide goal https://review.opendev.org/c/openstack/nova/+/829866 | |
| 04:29:47 | opendevreview | Ghanshyam proposed openstack/nova master: Complete phase-1 of RBAC community-wide goal https://review.opendev.org/c/openstack/nova/+/829866 | |
| 10:16:50 | gibi | sean-k-mooney, bauzas: I'm wondering that calling out to the sysfs of the compute host from nova's neturon code is something that breaks the virt driver separation. I mean the neutron interface code is called from the compute manager and that should be virt driver agnostic so it cannot assume it runs on Linux with sysfs. Currently we do call out to sysfs here | |
| 10:16:55 | gibi | https://github.com/openstack/nova/blob/0c31561792e0e13a9f8267e71fa484ab79957f04/nova/network/neutron.py#L1572-L1584 | |
| 10:18:09 | gibi | in comparision when I introduced pf_interface_name information for each VFs I did so via the virt driver instead of calling out to sysfs from the neutron code in https://review.opendev.org/c/openstack/nova/+/623543 | |
| 15:19:02 | gmann | gibi: bauzas: dansmith: rbac series is ready, pushed last patch with release notes also https://review.opendev.org/q/topic:bp%252Fpolicy-defaults-refresh-2 | |
| 15:20:35 | gmann | gibi: fixed your comment about swap volume API permission to continue the existing way cinder is accessing - https://review.opendev.org/c/openstack/nova/+/828670/4 | |
| 18:11:44 | opendevreview | Alexey Stupnikov proposed openstack/nova master: Add functional tests to reproduce bug #1960412 https://review.opendev.org/c/openstack/nova/+/830010 | |
| #openstack-nova - 2022-02-21 | |||
| 00:36:59 | opendevreview | Miguel Lavalle proposed openstack/os-vif master: Fix race with DPDK and vhostuserclient mode https://review.opendev.org/c/openstack/os-vif/+/830103 | |
| 09:41:01 | bauzas | hola folks | |
| 09:41:38 | gibi | bauzas: o/ | |
| 09:41:41 | bauzas | Uggla: looks like your karma helped my server to be back alive :) | |
| 09:41:58 | bauzas | just by a gchat ping, wow | |
| 09:41:59 | gibi | gmann: thanks I've started reading it this morning | |
| 09:42:14 | bauzas | gmann: will review it | |
| 09:43:06 | Uggla | bauzas, first time it happens to me! :) Most of the time I find bugs. ;) | |
| 09:43:19 | bauzas | it was fun | |
| 09:44:07 | bauzas | I was fighting for 2 hours with a rasppi not wanting to resurrect and like 1 min after your ping and like 10 reboots, it eventually rebooted | |
| 09:44:26 | bauzas | maybe a fsck | |
| 09:45:02 | bauzas | just take one day off and be prepared about a bad day :p | |
| 09:47:35 | Uggla | I have a question regarding: https://specs.openstack.org/openstack/nova-specs/specs/yoga/approved/libvirt-virtiofs-attach-manila-shares.html | |
| 09:50:50 | Uggla | Regarding the model we have share_mapping table and instance_uuid as a field. If I'm not wrong we have a one to one relationship between share and instance, correct ? | |
| 09:53:20 | Uggla | But a share can be attached to several instances. So the model may need to be changed. Am I wrong ? | |
| 09:56:02 | bauzas | hmmmm | |
| 09:57:07 | Uggla | I would say we need a share_uuid field on the instance table to have a 1 to n relation ? | |
| 09:58:31 | Uggla | I could update the spec, but I would like to know if I have understand it well. | |
| 10:01:44 | bauzas | Uggla: oh, I just read again the spec | |
| 10:02:11 | bauzas | Uggla: nothing prevents you to have a share_mapping table with multiple share_uuid records having the same UUID | |
| 10:03:23 | Uggla | so we will have several records for the same share with a diff uuid. | |
| 10:03:36 | Uggla | so we will have several records for the same share with a diff instance_uuid. | |
| 10:03:38 | bauzas | I guess lyarwood wanted to tell we would do the same like for BlockDeviceMapping table | |
| 10:04:24 | bauzas | where we have a UC be the mapping UUID itself | |
| 10:04:31 | bauzas | not the volume UUID | |
| 10:04:44 | bauzas | Uggla: https://github.com/openstack/nova/blob/master/nova/db/main/models.py#L590 | |
| 10:05:38 | bauzas | either way, the PK on the bdmmapping table is a single 'id' key | |
| 10:05:38 | kashyap | Some more documentation on it - https://docs.openstack.org/nova/latest/user/block-device-mapping.html | |
| 10:06:00 | bauzas | thanks kashyap | |
| 10:08:22 | gibi | gmann: thanks I've started reading the new PSs this morning | |
| 10:12:19 | Uggla | Ok thanks, so in that case, maybe the share_mapping table requires an index on instance_uuid ? | |
| 10:13:24 | bauzas | Uggla: this depends whether you want to query from this field | |
| 10:14:00 | bauzas | Uggla: but since you'll tag a FK on instances.uuid, it will automatically generate an index | |
| 10:14:16 | bauzas | :) | |
| 10:14:29 | Uggla | ok | |
| 10:20:17 | opendevreview | Pavlo Shchelokovskyy proposed openstack/nova master: Sort PCI devices by their address https://review.opendev.org/c/openstack/nova/+/830136 | |
| 10:24:33 | Uggla | Another question, looking at block device attachment, the api speaks directly to the compute api. Are there some specific rules that defines to speak through the conductor, or directly to the compute. Do we speak to the compute directly when we don't need to interact with the db at the first stage ? | |
| 10:24:41 | lyarwood | \o hey so yeah I thought I included a unique UUID per mapping between the instance and share? | |
| 10:26:45 | lyarwood | Uggla: the compute API isn't running on the compute, that's up in nova-api, the manager is the part running on the compute | |
| 10:27:58 | bauzas | lyarwood: I explained it to Uggla | |
| 10:28:13 | bauzas | https://specs.openstack.org/openstack/nova-specs/specs/yoga/approved/libvirt-virtiofs-attach-manila-shares.html#data-model-impact | |
| 10:28:21 | bauzas | Uggla: ^ | |
| 10:28:23 | lyarwood | cool thanks and sorry I don't have this IRC client open anymore, only just saw the email :) | |
| 10:28:38 | Uggla | lyarwood, agreed my question is more the path api --> compute vs api --> cond --> compute ? | |
| 10:29:06 | lyarwood | Uggla: we only use the latter for long running tasks iirc like rebuilds, resizes etc | |
| 10:29:36 | lyarwood | Uggla: device attachments that are simple async operations tend to go directly between the api and compute | |
| 10:33:08 | bauzas | ++ | |
| 10:33:47 | bauzas | also if we already know the compute | |
| 10:33:57 | Uggla | lyarwood, so the manila one drops down to the simple async op case, correct ? | |
| 10:34:37 | lyarwood | Yeah | |
| 10:34:51 | lyarwood | and tbh it should be a noop at the moment as the instance is shutoff anyway | |
| 10:35:28 | lyarwood | starting the instance will recreate it within the libvirt driver and the logic to attach the mount needs to live there initially | |
| 10:35:40 | lyarwood | until we support hot plug | |
| 10:36:58 | Uggla | lyarwood, ok thx. | |
| 10:37:58 | Uggla | thank you for the answers, I think I can continue. | |
| 11:00:59 | opendevreview | yuval proposed openstack/nova master: Lightbits LightOS driver https://review.opendev.org/c/openstack/nova/+/821606 | |
| 11:03:21 | opendevreview | yuval proposed openstack/nova master: Lightbits LightOS driver https://review.opendev.org/c/openstack/nova/+/821606 | |
| 11:13:46 | sean-k-mooney | gibi: am well the pci module also is virt dirver indepenent and we explictily call sysfs in many cases to avoid depening on the virt driver | |
| 11:13:59 | sean-k-mooney | gibi: so that is already an established patteren | |
| 11:14:02 | gibi | :/ | |
| 11:14:14 | gibi | so basically nova-compute cannot run on windows with hyperv | |
| 11:14:19 | gibi | or it can but never handle PCI devices | |
| 11:14:34 | sean-k-mooney | gibi: they dont support pci device management | |
| 11:14:51 | gibi | yeah I figure that they cannot right now | |
| 11:14:55 | sean-k-mooney | so ya on windows they would have ti impelent all the fucntions in a windows compatiable way | |
| 11:15:16 | gibi | interestingly whent he pf_interface_name was added for QoS that was added via the virt driver interface | |
| 11:15:21 | sean-k-mooney | in os-vif we added an indriection layer in teh few places we needed it | |
| 11:15:44 | sean-k-mooney | gibi: yes which i changed since that was unreliable | |
| 11:15:58 | sean-k-mooney | due to libvirt design choices | |
| 11:16:16 | sean-k-mooney | mainly the way the cache and how that interacts with udev | |
| 11:17:31 | sean-k-mooney | gibi so right now the neutron use of sysfs is still confied to the sriov path | |
| 11:17:52 | sean-k-mooney | so i dont think this usage breaks windows support since that was already not supported | |
| 11:18:06 | sean-k-mooney | gibi: are there other usages that you found that would be common | |
| 11:18:16 | gibi | sorry I meant parent_ifname | |
| 11:18:26 | gibi | that is still done via the virt driver interface https://github.com/openstack/nova/blob/master/nova/virt/libvirt/host.py#L1321 | |
| 11:18:53 | sean-k-mooney | ah there | |
| 11:19:14 | gibi | sean-k-mooney: the new smartnic feature introduced a set of new dependencies between nova's neturon code (called from the compute manager) and sysfs | |
| 11:19:22 | sean-k-mooney | well its calling into the pci module to do it | |
| 11:19:39 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/host.py#L1322 | |
| 11:19:51 | sean-k-mooney | so that is not actully calling libvirt anymore | |
| 11:19:53 | gibi | yes but the call coming from the libvirt driver | |
| 11:20:05 | gibi | so the nova-compute does not depend on the sysfs in that case | |
| 11:20:10 | gibi | as the virtdirver hides it | |
| 11:20:37 | sean-k-mooney | yes this is genergating the virt independent view of the pci devices that is pass to the pci tracker | |
| 11:20:49 | sean-k-mooney | yes | |
| 11:21:33 | sean-k-mooney | gibi: so at one point i think i proposed storing the mac and vf number in addtion to the serial in the pci dev extra info | |
| 11:21:46 | sean-k-mooney | we could do that and remove the need to do this lookup entirly | |