| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-01 | |||
| 13:32:47 | bauzas | oh, the rpc call | |
| 13:33:02 | bauzas | lemme just send to the gate ricolin's work | |
| 13:33:09 | sean-k-mooney | bauzas: that an di guess i need to rev my follow up patch with actul tests | |
| 13:33:45 | sean-k-mooney | dansmith: im not agasint doint that if you think you will have time | |
| 13:34:04 | sean-k-mooney | but that probaly the main RFE that i think FFE might make sense for | |
| 13:34:20 | dansmith | sean-k-mooney: I was expecting to see a rev of the patch to move the regen to after the instance is destroyed and fix the actual writing that was failing | |
| 13:34:30 | dansmith | so I hadn't rebased my RPC stuff yet | |
| 13:34:31 | sean-k-mooney | the only other one might be the PCI series ebut have nto looked at it for two days | |
| 13:34:40 | dansmith | but that has to happen first right? | |
| 13:34:52 | sean-k-mooney | oh i wrote a ptach to fix config drive | |
| 13:35:10 | dansmith | oh is that ths? https://review.opendev.org/c/openstack/nova/+/855351/1 | |
| 13:35:16 | sean-k-mooney | yes | |
| 13:35:41 | gibi | sean-k-mooney: you are +2 up until the healing patches in the PCI and that is the realistic target there. If stephenfin will have no time to review them today then I will ask for an FFE for that. We let the scheduling part slip in any case | |
| 13:35:51 | bauzas | the mutable userdata has API impact | |
| 13:35:52 | dansmith | okay but that would need to be squashed or go in front right? | |
| 13:35:59 | bauzas | but I'm OK with FFE'ing if needed | |
| 13:36:16 | dansmith | bauzas: it would also be about half not-very-reviewed code at this point based on the look of the configdrive patch | |
| 13:36:30 | dansmith | so not really "just didn't get reviewed in time" | |
| 13:36:49 | sean-k-mooney | dansmith: yes or they split the patch in to non config drive and config drive | |
| 13:37:20 | dansmith | that would mean two microversions for effectively the same thing | |
| 13:37:30 | sean-k-mooney | dansmith: i basically started my patch so they would have a refernce for what needed to be done | |
| 13:37:36 | dansmith | unless we do the config regen and rpc ahead of exposing int the api | |
| 13:37:39 | bauzas | dansmith: I think we reviewed it good, but we got a bone | |
| 13:37:59 | bauzas | so, I'm OK with giving more time to review that bone fix | |
| 13:38:06 | dansmith | bauzas: I'm saying the code that needs to be written to make it landable would probably double the actual code in the patch | |
| 13:38:09 | sean-k-mooney | dansmith: yep we coudl do that so intialy it would not be invokeable from the api btut he code would be in place | |
| 13:38:30 | dansmith | sean-k-mooney: yeah that seems better to me | |
| 13:38:32 | bauzas | dansmith: then, we need to take this extratime to balance the risks and maybe not merge it | |
| 13:38:52 | bauzas | or decide we only merge half the things | |
| 13:39:12 | sean-k-mooney | dansmith: so you could proably combin your rpc code into the pathc i started then we could flip the order of them | |
| 13:39:13 | gibi | we could merge the part that support user data update with non config drive instances. | |
| 13:39:26 | sean-k-mooney | but that also means we need to other pepoel to agree to review this | |
| 13:39:33 | sean-k-mooney | since you and i are basicaly out at that point | |
| 13:40:12 | gibi | I can review the patches (I will be around 18:00 CEST today but I can spend time early tomorrow too) | |
| 13:40:31 | gibi | * I will be around until 18:00 CEST today | |
| 13:40:47 | dansmith | sean-k-mooney: right, that's a problem too | |
| 13:41:21 | dansmith | sean-k-mooney: so a patch in front that adds the flag to the reboot call, then the patch to make it regeneratable, then the api patch to do it for both types would be cleanest I think | |
| 13:41:47 | sean-k-mooney | dansmith: ya that sounds like a plan | |
| 13:42:07 | sean-k-mooney | it keeps just one micorversion | |
| 13:42:57 | sean-k-mooney | i can go writeh the tests need to make the rebuild patch complete if we agree to proceed in this direction | |
| 13:43:57 | dansmith | sean-k-mooney: ack, I'll rebase my rpc stuff | |
| 13:44:00 | sean-k-mooney | dansmith: it would proably make sense for you to write your patch directly off master and i could rebase and flip the order when your done | |
| 13:44:14 | dansmith | sean-k-mooney: yeah | |
| 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 | |