| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-03-11 | |||
| 08:42:51 | sean-k-mooney[m] | its set by nova in the libvirt xml | |
| 08:43:01 | ralonsoh | ok, this is what I was looking for | |
| 08:43:07 | sean-k-mooney[m] | ill find the code one sec | |
| 08:43:08 | ralonsoh | thanks! | |
| 08:46:22 | sean-k-mooney | so our LibvirtConfigGuestInterface has a vlan property https://github.com/openstack/nova/blob/master/nova/virt/libvirt/config.py#L1912 which is rendered into the xml for type direct and hostdeve vnic_type=direct is hostdev in this case and vnic_type=macvtap is direct... | |
| 08:46:24 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/config.py#L2015-L2019 | |
| 08:46:57 | ralonsoh | right, so the VLAN is set in the interface definition | |
| 08:47:00 | ralonsoh | thanks a lot! | |
| 08:48:11 | sean-k-mooney | that invloked form here https://github.com/openstack/nova/blob/master/nova/virt/libvirt/vif.py#L630-L657 | |
| 08:49:01 | ralonsoh | yes, this vif plug method I was aware of it | |
| 08:49:01 | sean-k-mooney | ralonsoh: so yes it defiend in the libvirt defintion and it will program the VLAN filter via the PF before it assigned the VF to qemu | |
| 08:49:09 | ralonsoh | but I didn't see where the VLAN was defined | |
| 08:49:13 | ralonsoh | but is in the XML | |
| 08:50:09 | ralonsoh | sean-k-mooney, ups, now you are here | |
| 08:50:15 | ralonsoh | qq about resource providers | |
| 08:50:24 | sean-k-mooney | sure | |
| 08:50:44 | ralonsoh | in Neutron, if we add BW info for an agent (SRIOV, OVN, etc) and a network | |
| 08:50:57 | ralonsoh | Neutron will use the API to create the RP, the inventories, etc | |
| 08:51:06 | ralonsoh | what if we remove the RP? | |
| 08:51:18 | ralonsoh | I don't think we have considered that | |
| 08:51:43 | ralonsoh | at least in OVN, that reads the RP info not from the configuration but from the chassis (so there is no API restart) | |
| 08:51:48 | sean-k-mooney | so the design at the time considered removing an RP that has allcoation ot be operator error | |
| 08:52:25 | ralonsoh | so if there is an error in the configuration (for example, the physnet name is incorrect) | |
| 08:52:33 | ralonsoh | do we need to manually remove the RP ? | |
| 08:52:36 | opendevreview | Maksim Malchuk proposed openstack/nova stable/2024.2: Allow hyphen in cinder catalog_info service-type https://review.opendev.org/c/openstack/nova/+/944009 | |
| 08:52:56 | ralonsoh | ah ah, so if there is allocation, it will fail | |
| 08:53:05 | sean-k-mooney | so it depends. we proposed but did not implemtne the idea of owner triats | |
| 08:53:34 | sean-k-mooney | the idea was that neutron or nvoa could add an owner trait to all RPs it owns | |
| 08:54:01 | ralonsoh | we use custom names for the physnets | |
| 08:54:02 | sean-k-mooney | that way it could check fi ther ewere any that were created that should not exist | |
| 08:54:54 | ralonsoh | hmmm I think this "deletion" operations are going to be more difficult than expected | |
| 08:54:56 | opendevreview | Maksim Malchuk proposed openstack/nova stable/2024.1: Allow hyphen in cinder catalog_info service-type https://review.opendev.org/c/openstack/nova/+/944010 | |
| 08:54:57 | sean-k-mooney | ralonsoh: right so you use thing slik same subtree | |
| 08:55:12 | ralonsoh | yes, the host->agent subtree | |
| 08:55:19 | ralonsoh | so we "own" this RP | |
| 08:55:38 | sean-k-mooney | ya so you can get all of the sub RPs in the subtree that match your nameign convention | |
| 08:55:41 | opendevreview | Maksim Malchuk proposed openstack/nova stable/2023.2: Allow hyphen in cinder catalog_info service-type https://review.opendev.org/c/openstack/nova/+/944011 | |
| 08:55:45 | sean-k-mooney | and delete any that shoudl not exist | |
| 08:55:57 | sean-k-mooney | if you have a OWNER_NEUTRON trait on them its safer | |
| 08:56:19 | sean-k-mooney | as even if there are two service usign the same naming convetion you can look at only the ones you created | |
| 08:56:24 | sean-k-mooney | that makes deleting it simper | |
| 08:56:34 | ralonsoh | yeah, this could be a good improvement for sure | |
| 08:56:56 | sean-k-mooney | for now however you know they starte with or contain phsenet right | |
| 08:56:57 | ralonsoh | that will mark our RP with no doubt | |
| 08:57:16 | ralonsoh | sean-k-mooney, and the agent RP, that is handled by Neutron | |
| 08:57:30 | sean-k-mooney | so you can must look at the RPs in the subtree for the agent | |
| 08:57:43 | sean-k-mooney | and remove any that are not in you current config. | |
| 08:57:45 | ralonsoh | ok, I think I know (maybe) how to do this | |
| 08:57:47 | ralonsoh | reference: https://issues.redhat.com/browse/OSPRH-14597 | |
| 08:57:52 | ralonsoh | I'll open a LP bug too now | |
| 08:57:58 | sean-k-mooney | if they have allcoation it indicates that the removal migt be in error | |
| 08:58:09 | ralonsoh | yes, this is important: we can't remove used RP | |
| 08:58:39 | sean-k-mooney | i trhink placement blocks it by default but i dont recall | |
| 08:58:55 | sean-k-mooney | when we are removign compute nodes we loop overa ll the allcoation on the RP and delete them first | |
| 08:58:59 | ralonsoh | yes, you are right | |
| 08:58:59 | sean-k-mooney | then delete the rp | |
| 08:59:06 | ralonsoh | in any case, I'll try this first | |
| 09:00:27 | sean-k-mooney | ralonsoh: if you can tell there is a rename | |
| 09:00:34 | sean-k-mooney | you can also do what is called a reshape | |
| 09:00:44 | sean-k-mooney | whish is the operation of moving allcoation between RPs | |
| 09:01:08 | sean-k-mooney | they are non tivial but its how we evovled the stucture over time | |
| 09:01:30 | sean-k-mooney | https://docs.openstack.org/api-ref/placement/#id86 | |
| 09:02:58 | sean-k-mooney | so for a rename you would add the new rp, reshape the inventories/allocation from the old then delete the old RP | |
| 09:03:09 | ralonsoh | I don't think we need to implement this reshape (I think) | |
| 09:03:23 | ralonsoh | just remove the RP that is un-configured | |
| 09:03:32 | sean-k-mooney | ya in this case you dont | |
| 09:03:37 | sean-k-mooney | at least not for that jira | |
| 09:03:51 | sean-k-mooney | just letting you know that api exists if you need it in the future | |
| 09:04:13 | ralonsoh | for sure, good to know this! | |
| 09:51:53 | sahid | o/ | |
| 09:52:31 | sahid | quick question guys, is there a way to stop provision on a specific AZ, or at least a way to do it | |
| 09:52:42 | sahid | I'm sure there is something but I can't remember how | |
| 09:54:36 | sean-k-mooney | sahid: no | |
| 09:54:45 | sean-k-mooney | sahid: not in general at least | |
| 09:54:59 | sean-k-mooney | you could proably hack it usign some of the filters | |
| 09:56:49 | sahid | I think it should be an interesting feature, don't you think? | |
| 09:56:57 | sean-k-mooney | in general no :) | |
| 09:57:14 | sean-k-mooney | we could add someign like disablign an az | |
| 09:57:23 | sean-k-mooney | it has a staus but it does nothing | |
| 09:57:25 | sahid | ahah ...I hould have bet for your response :-) | |
| 09:57:45 | sean-k-mooney | today the status fo an az is just if any compute service is up and not disabled | |
| 09:58:02 | sean-k-mooney | sahid: why do you want to disable it? | |
| 10:00:40 | sahid | sean-k-mooney: it's to validate the resilience if we lose an AZ | |
| 10:00:52 | sahid | they do such check for everything | |
| 10:01:20 | sean-k-mooney | AZ are not for fault tollerance | |
| 10:01:33 | sean-k-mooney | so if your usign them for that you are starting form a broken foundation | |
| 10:01:53 | sahid | it's not the point | |
| 10:05:15 | sean-k-mooney | allowing an az to be disabled externally woudl be an api change and need a spec. im not entirly sure that a good thing but its not terible | |
| 10:05:38 | sean-k-mooney | today you could jsut disbale the computes theat are in an az to get the same effect | |
| 10:07:18 | sahid | sean-k-mooney: it's basically what we are going to do, but they are lot of computes to disable I was trying to think about something else | |
| 10:08:17 | sahid | i don't say it's something nova wants, perhpas it's something useful only for us | |
| 10:08:49 | sean-k-mooney | the problem is really what are the semantics | |
| 10:08:57 | sean-k-mooney | do we filter it form the list of AZs | |
| 10:09:31 | sean-k-mooney | do we impact any lifecycle operation on hosts assocated with the az | |
| 10:09:42 | sean-k-mooney | i.e. disabel reboot? start? | |
| 10:10:18 | sahid | from our use case it is just about to stop provisoning on a specific az | |
| 10:10:51 | sahid | wich may beuseful for upgrade or deployment if we can do that easily | |
| 10:10:54 | sean-k-mooney | i feel like this would be a new trait added to all host of a given az and an prefilter to forbid that trait | |
| 10:16:36 | sahid | sean-k-mooney: in that way we don't need an API change, right? | |
| 10:17:04 | sean-k-mooney | no you still do if you want a api call to be able to disable the az | |