| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-08-31 | |||
| 09:07:17 | bauzas | agreed on flipping the microversions | |
| 09:07:33 | bauzas | at least for not blocking bfv rebuild | |
| 09:07:46 | gibi | sean-k-mooney[m]: do we store the config drive in lvm / rbd? I thought it is always a file on disk | |
| 09:08:03 | gibi | but agree if this is complicate then punt it | |
| 09:08:07 | bauzas | for userdata, we can't just tell "sorry you can't update your data because config drive" as this is a config-driven API behaviour | |
| 09:08:40 | bauzas | could we have a separate flag that would say "I allow you to update your userdata" and leave the responsibility to the ops to enable it ? | |
| 09:08:51 | kashyap | gibi: I think it's a file on the disk, too, the config-drive | |
| 09:08:54 | bauzas | with a caveat saying there could be perm issues with configdrive | |
| 09:09:05 | sean-k-mooney[m] | gibi: good question i belvie we do looking at the code but ill check. i know swap gets created on rbd | |
| 09:09:17 | sean-k-mooney[m] | and this appears to be using the generic imagebackend code | |
| 09:09:21 | sean-k-mooney[m] | but ill confimr again | |
| 09:10:32 | sean-k-mooney[m] | bauzas i dont think we should hack around this | |
| 09:10:54 | sean-k-mooney[m] | the feature is broken currently if you use config deive and i think its important that works | |
| 09:11:04 | sean-k-mooney[m] | espcially since we added a stadard trait for this | |
| 09:11:23 | bauzas | that's my point | |
| 09:11:28 | sean-k-mooney[m] | we could simple not report that for the libvirt driver i guess | |
| 09:11:47 | bauzas | in theory, we could only allow to update userdate if configdriver isn't in use | |
| 09:11:52 | bauzas | userdata* | |
| 09:11:52 | sean-k-mooney[m] | so in this cycle no driver would report it so you could only use this if you did not have config drive | |
| 09:12:12 | sean-k-mooney[m] | bauzas: that works today i think | |
| 09:12:13 | bauzas | but I don't wanna leak a config-driven behaviour | |
| 09:12:23 | sean-k-mooney[m] | it would not be config driven behavior | |
| 09:12:24 | bauzas | sean-k-mooney: then this is documentation | |
| 09:12:35 | sean-k-mooney[m] | we just set the compute capablity trait to false for libvirt | |
| 09:12:52 | sean-k-mooney[m] | and then when config drive works we set it to true | |
| 09:13:33 | sean-k-mooney[m] | bauzas: either way im not sure its reasonable of use to ask whoami-rajat to wait any longer given the state of the user data patch | |
| 09:13:46 | bauzas | agreed again | |
| 09:13:57 | bauzas | we should ask to flip the microversions | |
| 09:15:42 | sean-k-mooney[m] | so flip microversion and split user data patch in two. setting the capablity trait to false in all drivers in the first one and the second patch and then implemnte the config drive rebuild adn rpc change | |
| 09:16:17 | sean-k-mooney[m] | ahtough that still feels a bit wrong | |
| 09:16:18 | bauzas | rpc change becaaaaause ? | |
| 09:17:00 | sean-k-mooney[m] | because currently it uses a dirty flag in the instance system metadata to say the config drive need to be rebuilt | |
| 09:17:37 | sean-k-mooney[m] | and dansmith made a very valid point tha tthat a shadow rpc interface and we should have added that as a parmater to the reboot rpc call | |
| 09:17:54 | sean-k-mooney[m] | so that was already requested as a followup | |
| 09:17:59 | gibi | I'm OK to only allow user data update for non config drive instances in Zed. That is a good enough compromise. Also config drive is just half config drive, as it can also be requested via the API | |
| 09:18:18 | gibi | *config drive is just half config driven | |
| 09:18:43 | sean-k-mooney[m] | yes it can thats how i was testing | |
| 09:19:05 | sean-k-mooney[m] | it can be forced via nova.conf but its user requestable as you said | |
| 09:19:59 | gibi | as a side note I found a bug in the allocation candidate filtering in the PCI series. | |
| 09:20:14 | gibi | so I think what is realistic there is to land the healing part | |
| 09:20:16 | gibi | up until https://review.opendev.org/c/openstack/nova/+/850468/20 | |
| 09:20:50 | gibi | stephenfin: Sean is +2 til ^^ so if you have time :) | |
| 09:21:08 | sean-k-mooney[m] | yes that was the partion i tought made sense if we did not land it all | |
| 09:21:30 | stephenfin | okay | |
| 09:21:41 | sean-k-mooney[m] | thats everything except the schduler part | |
| 09:21:43 | gibi | also in the light of the recent shadow RPC discussion I feel that storing data in InstancePCIRequest.extra_info is also shadowy in my series | |
| 09:22:07 | gibi | sean-k-mooney[m]: yepp, that already gives visibility of the PCI resource inventories in placement which is good to have | |
| 09:22:29 | sean-k-mooney[m] | it would have been nice to have the split pools by PF change | |
| 09:22:42 | gibi | we could land that, that is not effected by the bug | |
| 09:23:02 | sean-k-mooney[m] | that would be nice since it gives preference to PFs without VFs when you ask for a PF | |
| 09:23:03 | gibi | it does not do any externally visible change\ | |
| 09:23:22 | gibi | I'm not sure it is a real preference or just an ordering change | |
| 09:23:29 | gibi | I have to look if we sort the pool | |
| 09:23:52 | sean-k-mooney[m] | i always tought the way we allocated was more or less deterministic | |
| 09:24:23 | sean-k-mooney[m] | at least it has been stable enough for use to use in the functional tests without intermient failures | |
| 09:24:31 | gibi | it is stable | |
| 09:24:44 | gibi | but it might be not stable do to sorting | |
| 09:24:55 | gibi | but due to simple iteration order of devices / pools | |
| 09:25:03 | sean-k-mooney[m] | ack | |
| 09:25:20 | bauzas | sean-k-mooney: so I've read https://review.opendev.org/c/openstack/nova/+/816157/15 | |
| 09:25:23 | sean-k-mooney[m] | so i guess we can look at that again and confirm if it is of benifit | |
| 09:25:34 | bauzas | sean-k-mooney: can you request for the patch split and the other microversion ? | |
| 09:25:37 | gibi | sean-k-mooney[m]: yes, I will look at the ordering | |
| 09:25:51 | bauzas | I can leave some comments but I'm way behind | |
| 09:25:54 | gibi | I have to drop for an hour now for an early lunch but I will be back after | |
| 09:26:15 | sean-k-mooney[m] | bauzas: sure | |
| 09:26:21 | bauzas | thanks | |
| 09:26:40 | bauzas | I'll review quickly the bfv rebuild series | |
| 09:26:56 | bauzas | both you and gibi gave +2s but I'll do my glance quickly | |
| 09:27:14 | bauzas | and I'll tell whoami-rajat to respin the API patch with 2.93 | |
| 09:27:21 | gibi | bauzas: you could look at the viommu one too | |
| 09:27:43 | bauzas | gibi: yup, on my list | |
| 09:32:01 | sean-k-mooney[m] | https://review.opendev.org/c/openstack/nova/+/816157/15#message-f9bcfb9f6d0115f20223c4cd1e91d5c5428798d7 | |
| 09:32:06 | sean-k-mooney[m] | done ^ | |
| 09:32:51 | sean-k-mooney[m] | whoami-rajat: dansmith do you have time to update the BFV serise to use 2.93 and rebase to master | |
| 09:32:52 | bauzas | thanks | |
| 09:33:16 | sean-k-mooney[m] | its too early for them but they should see it when they get online | |
| 09:36:38 | sean-k-mooney[m] | gibi i think you are right by the way. there is no preference its just the fact we create the pool with just the PF before we create the pool with the VF in those tests i think so its just down to pciadress/pool ordering i think. | |
| 09:37:32 | sean-k-mooney[m] | we could add a prefernce but that is out of scope of the spec so dont worry about it | |
| 09:45:24 | sean-k-mooney[m] | ... its a annoying i think i see how to fix configdrive | |
| 09:45:57 | sean-k-mooney[m] | for RBD we do infact import the local config drive into ceph and it will creatly delete and recreate it if required | |
| 09:46:40 | sean-k-mooney[m] | if i use a tempory path to to generate teh new config drive and implemnente import file for the other backends then that should fix it | |
| 09:47:13 | sean-k-mooney[m] | for flat/qcow that jsut an atomic move to the normal localtion via privesep to workaround the permission issue | |
| 09:47:29 | sean-k-mooney[m] | for lvm its not much harder to do but its a little more work | |
| 09:48:25 | sean-k-mooney[m] | so im still going to try and do that so that they have a refernce patch for how to fix it | |
| 10:03:27 | bauzas | sean-k-mooney: gibi: fwiw https://review.opendev.org/c/openstack/nova/+/820368/comment/bd35c4c9_0ad9dd3d/ I'm asking to update https://docs.openstack.org/nova/latest/user/support-matrix.html#operation_rebuild in the API patch | |
| 10:11:27 | sean-k-mooney[m] | bauzas: gibi ok i have a working version of the config drive part | |
| 10:11:48 | sean-k-mooney[m] | i can push it for review and then work on tests to see what people think | |
| 10:14:46 | bauzas | ok | |
| 10:14:58 | bauzas | I need to bail out for lunch but I'll be back later | |
| 10:26:49 | opendevreview | sean mooney proposed openstack/nova master: support configdrive rebuilding https://review.opendev.org/c/openstack/nova/+/855351 | |
| 10:44:13 | whoami-rajat | sean-k-mooney[m], ack, on it | |
| 11:35:33 | opendevreview | Rajat Dhasmana proposed openstack/nova master: Add support for volume backed server rebuild https://review.opendev.org/c/openstack/nova/+/820368 | |
| 11:35:34 | opendevreview | Rajat Dhasmana proposed openstack/nova master: Add conductor RPC interface for rebuild https://review.opendev.org/c/openstack/nova/+/831219 | |
| 11:35:34 | opendevreview | Rajat Dhasmana proposed openstack/nova master: Add API support for rebuilding BFV instances https://review.opendev.org/c/openstack/nova/+/830883 | |
| 11:37:40 | whoami-rajat | sean-k-mooney[m], bauzas gibi dansmith ^^ rebased to 2.93 | |
| 11:37:59 | bauzas | ++ | |
| 11:38:11 | whoami-rajat | once this merges, i will change novaclient, openstackclient, tempest changes as well | |
| 11:39:44 | whoami-rajat | bauzas, I wasn't sure what your ask was regarding the support matrix change, can you check if this is the change you intended ? https://review.opendev.org/c/openstack/nova/+/830883/29..30/doc/source/user/support-matrix.ini | |
| 11:39:53 | whoami-rajat | https://review.opendev.org/c/openstack/nova/+/830883/30/doc/source/user/support-matrix.ini | |