| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-01 | |||
| 13:44:29 | bauzas | I'm OK with having 3 patches, the API one being the latest | |
| 13:44:48 | bauzas | and this being FFE, so we have 1 week to correctly look at all of this | |
| 13:47:50 | bauzas | elodilles: when is the exact deadline for cycle highlights ? | |
| 13:47:54 | bauzas | today or tomorrow ? | |
| 13:48:32 | bauzas | one day, the marketing team will understand how crazy it is to ask for feature docs deliveries at the FeatureFreeze (and even before) | |
| 13:48:45 | bauzas | while RC1 time would be so easier | |
| 13:49:15 | bauzas | this is just, I need to take 1 hour of my time for writing something while we're on fire | |
| 13:50:53 | sean-k-mooney | on the plus side tempest-integrated-compute forces config drive and that passed so at least that change in logic works for normal boots https://zuul.opendev.org/t/openstack/build/98cfa86b93974d79b1d43c29433d7e48/log/controller/logs/etc/nova/nova-cpu_conf.txt#17 | |
| 13:52:26 | sean-k-mooney | i also checked that locally but nice to see it in ci too. | |
| 13:53:33 | elodilles | bauzas: i think there is no strict deadline for today, we will merge it tomorrow if it will be ready only around that time :) | |
| 13:54:16 | sean-k-mooney | elodilles: i think the remidner was asking for it yesterday | |
| 13:54:47 | opendevreview | Justas Poderys proposed openstack/nova-specs master: Improve multiqueue network adapter support https://review.opendev.org/c/openstack/nova-specs/+/855514 | |
| 13:54:54 | sean-k-mooney | but i guess bauzas point was we might not know the full feature set until we hit FF | |
| 13:54:59 | bauzas | elodilles: surely there is no problem, but I wonder why such rush | |
| 13:55:01 | sean-k-mooney | or RC1 if we have FFEs | |
| 13:55:12 | bauzas | elodilles: I just replied to your email fwiw | |
| 13:55:27 | bauzas | I guess my point is not if I can deliver later | |
| 13:55:52 | bauzas | but rather asking for an official move to RC1 | |
| 13:56:10 | sean-k-mooney | elodilles: oh you just said this week | |
| 13:56:34 | bauzas | sean-k-mooney: https://releases.openstack.org/zed/schedule.html#cycle-highlights | |
| 13:56:59 | sean-k-mooney | yep | |
| 13:57:05 | sean-k-mooney | looking at it now | |
| 13:57:10 | bauzas | the schedule officially says the week of Zed-3 | |
| 13:57:25 | bauzas | this is non-trivial | |
| 13:57:45 | sean-k-mooney | i can understand that they might want to have them read for RC1 | |
| 13:58:11 | sean-k-mooney | but the week beteeen the two woudl be a better comproise | |
| 14:01:58 | dansmith | sean-k-mooney: so I'm bringing in the libvirt driver reconfigure_configdrive() method from the original patch, but I should move that until after the self.destroy() yeah? | |
| 14:02:46 | sean-k-mooney | well it need to get called via the callback | |
| 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 | |