| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-01 | |||
| 14:03:10 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/855351/1/nova/virt/libvirt/driver.py#3978 | |
| 14:03:15 | dansmith | I guess I need to look at your patch | |
| 14:03:36 | elodilles | bauzas: if everything goes accroding to plans, then by FF a team knows every feature which were merged. of course, FFEs can alter the picture, but that i think is acceptable. Be the most part of the highlights merged and update the rest if needed as soon as possible. IMO. | |
| 14:03:39 | sean-k-mooney | tl;dr building the config drrive need info generage by libvirt in the xml | |
| 14:03:42 | elodilles | bauzas: "The Zed-3 milestone marks feature freeze for projects following the release:cycle-with-rc model. No featureful patch should be landed after this point. Exceptions may be granted by the project PTL." | |
| 14:04:32 | sean-k-mooney | elodilles: yes but generaly review bandwith consumes all the ptls time | |
| 14:04:56 | sean-k-mooney | elodilles: so the project team does not have time to reflect on the feature that lanaded over the cycle to see what should be highlighted | |
| 14:05:02 | bauzas | sean-k-mooney: that's my point | |
| 14:05:29 | dansmith | sean-k-mooney: ah okay so actually yours should go first then | |
| 14:05:36 | bauzas | this is counterproductive for me to block 2 hours of my time on a FF Thursday in order to write a document I could be able to write the week after | |
| 14:05:43 | dansmith | otherwise I'm, plumbing rpc that lies about what it does | |
| 14:06:07 | bauzas | the rpc thing concerns me | |
| 14:06:17 | bauzas | do we need to have a service check on the API ? | |
| 14:06:32 | sean-k-mooney | i think we can do them in any order intially and jsut fix it once we have the first verion of all the patches | |
| 14:06:33 | dansmith | bauzas: yes because it's a case | |
| 14:06:36 | dansmith | *cast | |
| 14:07:00 | bauzas | dansmith: agreed, particularly because of the non-blocking RPC call then | |
| 14:07:13 | dansmith | bauzas: the original patch was checking with tempest, but if we have an rpc version, we can use the version pin, or check service version | |
| 14:07:18 | bauzas | and an ERROR would be terrible to manage | |
| 14:08:14 | dansmith | bauzas: since this is a new param, I was going to make rpcapi refuse to send if you ask for the new flag, per usual, so the api will catch and handle that, knowing it was not allowed | |
| 14:08:33 | elodilles | bauzas: ack, i see. to tell you the truth i don't know when exactly marketing team processes the cycle highlights, so maybe we have here some days until they'll need it (especially due to FFEs) | |
| 14:08:34 | dansmith | but all that has to get tested for sure | |
| 14:09:03 | sean-k-mooney | elodilles: by the way can you add https://review.opendev.org/c/openstack/nova/+/833435 to your list whenever you have time | |
| 14:10:41 | elodilles | sean-k-mooney: ack, looking | |
| 14:11:02 | elodilles | bauzas: i'll answer to your mail as well :) | |
| 14:11:26 | sean-k-mooney | its just a backport making its way down to train so not urgent i came across the downstream bug and realise i should proably followup | |
| 14:11:59 | bauzas | dansmith: oh, right | |
| 14:12:16 | bauzas | dansmith: just exception handling at the API level, you're right | |
| 14:12:48 | bauzas | elodilles: don't get me wrong, I wasn't grumbling, I was just pointing out my problem for discussion | |
| 14:13:08 | bauzas | maybe the foundation folks don't exactly get what's happening at FF | |
| 14:13:16 | bauzas | in particular with the big projects | |
| 14:27:56 | elodilles | bauzas: i summarized what i think about this in my mail. let's see if someone from Marketing or Release team has different view o:) | |
| 14:28:11 | elodilles | sean-k-mooney: the patch looks valid, +2'd | |
| 14:33:29 | sean-k-mooney | ill slowly refersh those patches as they merged but give we are are FF im also trying to limit the ci usage | |
| 14:35:32 | elodilles | sean-k-mooney: ++ | |
| 14:53:42 | opendevreview | sean mooney proposed openstack/nova master: support configdrive rebuilding https://review.opendev.org/c/openstack/nova/+/855351 | |
| 14:53:43 | opendevreview | sean mooney proposed openstack/nova master: add support for updating server's user_data https://review.opendev.org/c/openstack/nova/+/816157 | |
| 14:54:19 | sean-k-mooney | dansmith: that wont work ^ but there in the correct order now and i can start on the tests | |
| 14:54:51 | dansmith | sean-k-mooney: okay but we can't land an RPC version that says it does a thing when it doesn't | |
| 14:55:04 | dansmith | sean-k-mooney: so I think your thing needs to be in front with "if False" or something | |
| 14:55:12 | dansmith | and I'll change that to "if the thing is enabled:" | |
| 14:55:46 | sean-k-mooney | dansmith: something like https://review.opendev.org/c/openstack/nova/+/855351/2/nova/virt/libvirt/driver.py#3879 | |
| 14:56:00 | sean-k-mooney | which is never set anywhere to True | |
| 14:56:19 | sean-k-mooney | and this if https://review.opendev.org/c/openstack/nova/+/855351/2/nova/virt/libvirt/driver.py#5011 | |
| 14:56:36 | dansmith | yeah | |
| 14:57:25 | sean-k-mooney | so i was thinking you could start a patch on top of the first one or if you want i can proably do it based on the termbin you provided | |
| 14:57:45 | sean-k-mooney | you will be quicker at that then me since its been a while since i toughed rpc but either way | |
| 14:58:19 | sean-k-mooney | im going to work on the base patch and get it to pass unit and func tests | |
| 14:58:34 | dansmith | yeah, I'm working on the rpc stuff already | |
| 14:58:50 | dansmith | I think that base patch will work now | |
| 14:59:43 | sean-k-mooney | it shoudl work in devstack im expecting the unit test to bitch about the extra paramter to _hard_reboot | |
| 15:04:15 | bauzas | hmm, are configdrivers only supported by libvirt N? | |
| 15:04:20 | bauzas | configdrives | |
| 15:04:30 | bauzas | I'm afraid of https://review.opendev.org/c/openstack/nova/+/816157/16/nova/virt/driver.py | |
| 15:04:36 | sean-k-mooney | techinially they are supproted by other drivers i think | |
| 15:04:38 | bauzas | trampling all our drivers but libvirt | |
| 15:04:39 | gibi | bauzas: nope, it is supported by other drivers too | |
| 15:04:59 | bauzas | that's super late for them to support them | |
| 15:05:07 | bauzas | s/them/this | |
| 15:05:08 | sean-k-mooney | they dont need too | |
| 15:05:13 | sean-k-mooney | they just wont be able to use this feature | |
| 15:05:26 | sean-k-mooney | i think that was in the spec | |
| 15:05:41 | sean-k-mooney | either way this was only planned to be implented by libvirt | |
| 15:05:50 | sean-k-mooney | at least for now | |
| 15:05:58 | bauzas | hmmmm | |
| 15:06:14 | gibi | so we need to detect the capability in the API and reject the reboot request | |
| 15:06:28 | bauzas | yup | |
| 15:06:29 | sean-k-mooney | thats in the patch currentlyyes | |
| 15:06:32 | gibi | if there is user_data update but the virt driver has no capability to regenerate | |
| 15:07:17 | bauzas | it wasn't stated a virt driver dependency in the spec https://review.opendev.org/c/openstack/nova-specs/+/816542/7/specs/zed/approved/update-userdata.rst | |
| 15:07:24 | sean-k-mooney | by the way we can now drop the object changes | |
| 15:07:42 | bauzas | this change seems to me more and more fragile | |
| 15:07:45 | sean-k-mooney | bauzas: well im not going to have time to work on ironic by monday | |
| 15:07:57 | bauzas | sean-k-mooney: I'm not asking you to do such things | |
| 15:08:04 | gibi | (it is not just ironice) | |
| 15:08:05 | sean-k-mooney | so hehe i think we were reving this as libvirt only or at least i was | |
| 15:08:10 | bauzas | but I point out how fragile this is | |
| 15:08:17 | sean-k-mooney | gibi: ya i know | |
| 15:08:33 | bauzas | and again, this wasn't explained in the spec | |
| 15:08:34 | sean-k-mooney | ironic would just be the most painful | |
| 15:08:55 | sean-k-mooney | bauzas: orgianly in the spec they planned to only do it for the metadta api | |
| 15:08:55 | bauzas | I was having concerns with this spec because I thought it wasn't really a needed usecase | |
| 15:09:07 | sean-k-mooney | but then we pointd out config drive exsited and need to also work | |
| 15:09:07 | bauzas | sean-k-mooney: no, they said about configdrives too | |
| 15:09:16 | sean-k-mooney | bauzas: no i asked them to add that | |
| 15:09:25 | sean-k-mooney | they wanted api only | |
| 15:09:35 | bauzas | sean-k-mooney: yes, but I also said it was a problem | |
| 15:09:35 | sean-k-mooney | id did not want this to not work if you used config drive | |
| 15:10:06 | sean-k-mooney | so as it stands any driver that does not supprot the new metond will not report the trait | |
| 15:10:19 | sean-k-mooney | that need to be called out in the api ref | |
| 15:10:26 | sean-k-mooney | or other docs for this | |
| 15:10:39 | sean-k-mooney | we could put it in the driver suport matirx i guess | |
| 15:10:56 | sean-k-mooney | that proably beter long term | |
| 15:14:07 | sean-k-mooney | dansmith: only 6 failure for the extra paramater | |
| 15:14:28 | sean-k-mooney | i actully need the driver api change in the first patch too so ill add that | |
| 15:15:12 | gibi | I'm wondering about the virt driver api change | |
| 15:15:26 | dansmith | but bauzas' point about this not being supported by other drivers is legit | |
| 15:15:37 | dansmith | having features that look like swiss cheese is very confusing for users | |
| 15:15:47 | sean-k-mooney | gibi: i could drop that now actully | |
| 15:15:49 | gibi | I asked for it originally as I thought the reboot + regenerate logic can be orchestrated from the compute manager | |