| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-23 | |||
| 11:08:23 | bauzas | https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/reshape-provider-tree.html#proposed-change | |
| 11:08:58 | bauzas | gibi: every 60 secs (by default), the virt driver passes back the provider tree | |
| 11:09:09 | bauzas | so it can change it | |
| 11:09:57 | bauzas | but if the virt driver wants to modify the tree by punting new inventories and allocations from a RP to another one, then it needs to tell placement to move them | |
| 11:10:43 | bauzas | gibi: I can understand your concern, you don't want to move inventories or allocations, but just moving the parent | |
| 11:12:25 | bauzas | but then I guess that the resources would be modified | |
| 11:12:51 | bauzas | gibi: say, for example, with https://docs.openstack.org/placement/latest/user/provider-tree.html#filtering-by-tree | |
| 11:13:11 | bauzas | you would then get different candidates | |
| 11:13:44 | bauzas | that's why we need to be sure that we won't have different resources | |
| 11:14:50 | gibi | sure if I change the structure of the tree then the in_tree a_c queries will change | |
| 11:15:27 | gibi | regardless if I change the tree with reshape or just going in the db and change the parent_uuid of an RP | |
| 11:16:27 | gibi | as far as I see if I base the fix to reshape then the process is create new dev RP, rehaspe inv and alloc from old dev RP, change neutron ports to point to the new dev RP, deled old dev RP | |
| 11:16:46 | gibi | I think this would work | |
| 11:17:03 | gibi | but it creates a new RP instead of move the existing RP | |
| 11:17:15 | gibi | so it is more complicated that what I need | |
| 11:24:13 | openstackgerrit | Stephen Finucane proposed openstack/nova master: docs: Add a resource limits guide https://review.opendev.org/c/openstack/nova/+/781433 | |
| 11:24:13 | openstackgerrit | Stephen Finucane proposed openstack/nova master: docs: Add a real-time guide https://review.opendev.org/c/openstack/nova/+/781434 | |
| 11:24:14 | openstackgerrit | Stephen Finucane proposed openstack/nova master: docs: Remove duplicate TPM extra spec info https://review.opendev.org/c/openstack/nova/+/781435 | |
| 11:24:14 | openstackgerrit | Stephen Finucane proposed openstack/nova master: docs: Remove duplicated PCI passthrough extra spec info https://review.opendev.org/c/openstack/nova/+/781436 | |
| 11:24:15 | openstackgerrit | Stephen Finucane proposed openstack/nova master: docs: Add SEV guide https://review.opendev.org/c/openstack/nova/+/781437 | |
| 11:24:15 | openstackgerrit | Stephen Finucane proposed openstack/nova master: docs: Add CPU models guide https://review.opendev.org/c/openstack/nova/+/781438 | |
| 11:24:16 | openstackgerrit | Stephen Finucane proposed openstack/nova master: docs: Change formatting of hypervisor config guides https://review.opendev.org/c/openstack/nova/+/781439 | |
| 11:24:16 | openstackgerrit | Stephen Finucane proposed openstack/nova master: docs: Add libvirt misc doc https://review.opendev.org/c/openstack/nova/+/781440 | |
| 11:24:17 | openstackgerrit | Stephen Finucane proposed openstack/nova master: docs: Clarify host-model, host-passthrough differences https://review.opendev.org/c/openstack/nova/+/782410 | |
| 11:24:17 | openstackgerrit | Stephen Finucane proposed openstack/nova master: docs: Fold in MDS security flaw doc https://review.opendev.org/c/openstack/nova/+/782411 | |
| 11:24:18 | openstackgerrit | Stephen Finucane proposed openstack/nova master: api: Improve extra spec validator help texts https://review.opendev.org/c/openstack/nova/+/782412 | |
| 11:41:08 | gibi | bauzas: another issue. I need to keep the name of the device RP as nova depends on it | |
| 11:41:28 | gibi | and RP name needs to b unique | |
| 11:41:34 | bauzas | yup | |
| 11:41:35 | gibi | in placement | |
| 11:41:46 | bauzas | in general, we use (parent)_(name) | |
| 11:41:48 | gibi | so the create a new device RP way does not work | |
| 11:42:14 | sean-k-mooney | is this in relation to something speciric? | |
| 11:42:15 | bauzas | I wonder | |
| 11:42:58 | bauzas | sean-k-mooney: see above | |
| 11:43:31 | sean-k-mooney | im trying to read back but what i have got sofar is moving bandwith inventories via a reshape? | |
| 11:43:36 | bauzas | gibi: maybe you should just create a new reshape method | |
| 11:43:41 | bauzas | gibi: and then modify the names | |
| 11:43:47 | bauzas | in there | |
| 11:44:10 | bauzas | like : does the RP have the wrong parent UUID ? yes => ReshapeNeeded | |
| 11:44:11 | gibi | bauzas: ohh the RP name is settable, so we can use a temporary name | |
| 11:44:56 | bauzas | then, ReshapeNeeded will be provided so you could say 'ah, ReshapeNeeded, so create a new RP, modify the existing name, and then use this name for my new RP' | |
| 11:45:07 | sean-k-mooney | gibi: its setable only one i think | |
| 11:45:22 | sean-k-mooney | gibi: eg i dont think you can modify it after you create teh RP | |
| 11:45:24 | gibi | sean-k-mooney: parent (null-> nonnull) and name is settable | |
| 11:45:37 | gibi | as far as I see | |
| 11:45:45 | bauzas | gibi: this way, you wouldn't change the RPs after the compute service is restarted | |
| 11:45:58 | sean-k-mooney | there used to be a limiation around this but im tryign to recall what it was | |
| 11:46:07 | gibi | bauzas: these RPs are not handled by nova, so this reshape will happen in neutron :) | |
| 11:46:15 | bauzas | ah, shit, right | |
| 11:46:16 | gibi | bauzas: but besides that yes | |
| 11:47:28 | sean-k-mooney | allowing RPs to be reparented would be a much cleaner approch | |
| 11:47:36 | sean-k-mooney | i have asked for this in the past | |
| 11:47:49 | sean-k-mooney | to avoid the need to reshap | |
| 11:48:06 | bauzas | no | |
| 11:48:20 | bauzas | because you need to modify them just after restarting the service | |
| 11:48:25 | bauzas | and not after | |
| 11:48:35 | bauzas | or candidates would be different | |
| 11:48:47 | sean-k-mooney | bauzas: we have disucssed this in the past and i have nver been satifed with the answeres as to why changeing the parent is not allowed | |
| 11:49:55 | gibi | sean-k-mooney: agree reparenting in my specific case would be cleaner, a generic reparenting is dangerous in the other hand | |
| 11:50:10 | gibi | like moving an RP from one tree to other | |
| 11:50:18 | sean-k-mooney | i dont think its any more dangours then a reshap | |
| 11:50:18 | gibi | that would definitely break existing allocations | |
| 11:50:34 | sean-k-mooney | it may or it may not | |
| 11:50:43 | sean-k-mooney | there are several cases where it would not | |
| 11:51:25 | sean-k-mooney | gibi: setting the parent is what i was tinking of before not the name by the way | |
| 11:51:34 | sean-k-mooney | e.g. where we could only do it once | |
| 11:51:47 | gibi | sean-k-mooney: yeah, parent can only be set from null to non null | |
| 11:52:13 | sean-k-mooney | gibi: the bandwith RPs shoudl really be using the pci device addres not the netdev name by the way | |
| 11:52:52 | sean-k-mooney | i stongly advocated for not using the netdev name in the RP name when this was being first added | |
| 11:52:53 | gibi | sean-k-mooney: nova uses PCI address, neutron uses netdev name | |
| 11:53:34 | sean-k-mooney | right which is problematic | |
| 11:53:39 | gibi | as neutron handleds these RPs it got the netdev name and nova does a translation. | |
| 11:53:49 | sean-k-mooney | right i know | |
| 11:53:59 | sean-k-mooney | but i did not wnat it to use the netdev name in neutron at all | |
| 11:54:13 | gibi | thats a wide change ^^ | |
| 11:54:24 | gibi | as neturon used that even before qos | |
| 11:54:43 | sean-k-mooney | correct which has been broken for sriov for a long time | |
| 11:55:20 | sean-k-mooney | by the way i was not suggestign that neutron stops usign devname eveywhere | |
| 11:55:28 | sean-k-mooney | that is a sperate thing | |
| 11:55:41 | sean-k-mooney | just that we model device in placment with teh pci address | |
| 11:56:16 | sean-k-mooney | when we start modeling sriov vfs in placmnet we will need to use the PF pci address as part of the name for the VF inventores | |
| 11:56:47 | sean-k-mooney | other but that will be challing with qos | |
| 11:57:42 | sean-k-mooney | we shoudl not have different behavour with nic vs other pci devices so i dont see using the devname as a valid option for nova reporting pci device in the future | |
| 11:59:06 | gibi | sean-k-mooney: I agree that when we model the PFs in placement we need to do it right. and make the QoS related RPs aligned. | |
| 12:13:52 | gibi | sean-k-mooney: it is not impossile rename the device RPs in placement to use pci address, we just need to add some netdev -> PCI address translation code in the neturon sriov agent, and keep conditional logic in nova to look for old netdev names and new pci address names for an extra cycle to support rolling upgrade | |
| 12:14:41 | sean-k-mooney | how did the RP get move by the way | |
| 12:14:45 | sean-k-mooney | you mentioned a bugfix? | |
| 12:14:54 | sean-k-mooney | i assume that has been reverted? | |
| 12:15:17 | sean-k-mooney | and yes that is one way to adress that in the future | |
| 12:15:29 | gibi | sean-k-mooney: this fixed a bug https://review.opendev.org/c/openstack/neutron/+/696600 but broke the tree | |
| 12:15:40 | sean-k-mooney | the other way woul dbe to add a kind fo symlink or alias feature to placment | |
| 12:15:49 | sean-k-mooney | so we can refer to the same RP with different names | |
| 12:16:47 | sean-k-mooney | ah i rememebr this | |
| 12:17:27 | sean-k-mooney | gibi: what is currently broken by having them under the compute node RP | |
| 12:18:25 | gibi | sean-k-mooney: if you upgrade from Train to Ussuri in a way that you had QoS configured already in Train then the Ussuri neutron will error out | |
| 12:18:38 | gibi | if you deploy a new Ussuri then no visible problem seen | |
| 12:18:45 | sean-k-mooney | got it | |
| 12:18:56 | sean-k-mooney | so we dont have min bandwith testing in grenade | |
| 12:18:59 | gibi | this is why the problem went undetected for so long | |