| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-23 | |||
| 10:39:22 | bauzas | I see | |
| 10:39:31 | gibi | bauzas: which thread? We just figured this problem out yesterday | |
| 10:39:35 | bauzas | sec | |
| 10:39:53 | gibi | it does not cuase any scheduling issue at the momemnt, this is why it was hidden so long | |
| 10:40:06 | bauzas | title is '[ops] Bandwidth problem on computes' | |
| 10:40:20 | gibi | bauzas: nope, that is some physical bandwidht issue | |
| 10:40:28 | bauzas | ah yeah, just looked | |
| 10:40:54 | gibi | so the above bug does not case any issue toady as the agent RP is basically unused | |
| 10:41:20 | gibi | but I have a request to start tracking OVS packet processing capacity as a resource | |
| 10:41:45 | gibi | and as today the ovs agent has a 1-1 relationship with the ovs agent, the ovs agent RP would be a good place for that new resource | |
| 10:42:01 | bauzas | okay I see the problem | |
| 10:42:05 | lucasagomes | hi, can someone please take a look at https://review.opendev.org/c/openstack/nova/+/776419, https://review.opendev.org/c/openstack/nova/+/776944 and https://review.opendev.org/c/openstack/nova/+/776934 ? | |
| 10:42:06 | gibi | I mean the ovs agent has 1-1 relationship with OVS itself | |
| 10:42:22 | gibi | bauzas: so first I would like to fix the bug | |
| 10:42:25 | lucasagomes | These are small patches that will prevent the nova gate from breaking when we change the default network backend in DevStack to OVN next cycle | |
| 10:42:29 | gibi | and then introduce new resources | |
| 10:43:04 | gibi | lucasagomes: I don't expect that these patches will be merged before the RC1 and the stable/wallaby is cut. | |
| 10:43:44 | lucasagomes | gibi, ah fair enough ok | |
| 10:44:02 | gibi | lucasagomes: but kick me after the cut and I will find somebody to review them | |
| 10:44:17 | gibi | bauzas: so one way to fix it is to re-parent the device RP | |
| 10:44:20 | lucasagomes | gibi, that sounds good, thanks much! | |
| 10:44:30 | gibi | bauzas: under the agent RP as it was before Ussuri | |
| 10:44:58 | gibi | bauzas: anyhow I will look into the reshape way now | |
| 10:45:58 | gibi | that is a good tip | |
| 10:46:50 | gibi | s/tip/suggestion/ | |
| 10:49:34 | gibi | bauzas: hm, so /reshape moves inventory and allocation between RPs but it does not move RPs between parents | |
| 10:50:44 | gibi | so I could create a new device RP under the agent and move the inventory and the allocations from the old device RP to the new device RP and then delete the old device RP | |
| 10:51:02 | gibi | this could work from placement perspectiv | |
| 10:51:02 | gibi | e | |
| 10:52:44 | gibi | neutron port does store the uuid of the RP the port is allocation from. So that would need to change too | |
| 10:53:48 | bauzas | gibi: you provide a new tree with the reshape API | |
| 10:54:42 | gibi | bauzas: really? I don't see RPs provided in the API | |
| 10:54:50 | gibi | I see inventories and allocations | |
| 11:03:17 | gibi | bauzas: the vgpu reshape also create the pgpu RPs _before_ the placement reshape call https://github.com/openstack/nova/blob/3de7fb7c327db348d04d15d4cd3c4f811a336126/nova/virt/libvirt/driver.py#L8414 | |
| 11:05:07 | bauzas | gibi: sure, but we provided back the new provider tree by this method https://github.com/openstack/nova/blob/3de7fb7c327db348d04d15d4cd3c4f811a336126/nova/virt/libvirt/driver.py#L8380 | |
| 11:05:33 | bauzas | gibi: so, we provide a new tree and then we look at the allocations | |
| 11:05:43 | bauzas | if there are some of them, then we call the reshape API | |
| 11:06:06 | bauzas | https://github.com/openstack/nova/blob/3de7fb7c327db348d04d15d4cd3c4f811a336126/nova/virt/libvirt/driver.py#L8102 | |
| 11:06:29 | bauzas | s/allocs/inventories | |
| 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 | |