| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-08-31 | |||
| 08:37:32 | gibi | bauzas: you won :) | |
| 08:37:37 | bauzas | \o/ | |
| 08:40:30 | hkominos | thanks you guys ! | |
| 08:40:58 | bauzas | gmann: good spot for the WIP status on my election patch | |
| 08:41:31 | bauzas | gmann: that's because I flagged the WIP status directly in Gerrit when I created the PS1 in Aug | |
| 08:41:45 | bauzas | now the patch is in active state | |
| 09:00:39 | sean-k-mooney[m] | gibi: this is such a can of worms | |
| 09:01:40 | sean-k-mooney[m] | i think to make this work we need to delete the old config drive first but that means we neeed to deal with all the image backends seperately since they dont have a rm() function | |
| 09:02:48 | bauzas | sean-k-mooney: a tl:dr about the problem ? | |
| 09:02:50 | sean-k-mooney[m] | i can add one but i was hoping this would be simple and then i rememebred this should also work for lvm and rbd so i cant just delete the file | |
| 09:03:22 | sean-k-mooney[m] | bauzas: the user data update feature is trying to rebuild the config deive on hard reboot if you updated the user data | |
| 09:03:30 | sean-k-mooney[m] | btu that fails with a permission denied\ | |
| 09:03:53 | sean-k-mooney[m] | i belive that is because the disk is owned by qemu | |
| 09:04:47 | sean-k-mooney[m] | so nova cant updated it and this need to work for rbd and lvm anyway so i cant really just assume its a file on disk and chown it | |
| 09:05:16 | sean-k-mooney[m] | the user_data feature is blocking the BFV rebuild feature because of the micorversion order | |
| 09:05:35 | sean-k-mooney[m] | so i was trying to unblock that but we are just going to have to change the order | |
| 09:06:21 | sean-k-mooney[m] | make BFV rebuild 2.93 and likely punt mutable user_data to AA | |
| 09:06:53 | sean-k-mooney[m] | there are other issue with rpc/testing in the userdata patch that likely wont get adressed without a FFE | |
| 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 | |