| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-11-23 | |||
| 07:58:55 | opendevreview | Takashi Kajinami proposed openstack/nova master: Detect maximum number of SEV guests automatically https://review.opendev.org/c/openstack/nova/+/899381 | |
| 08:00:27 | tkajinam | sean-k-mooney, bauzas ^^^ I've created as bp https://blueprints.launchpad.net/nova/+spec/libvirt-detect-sev-max-guests and link it from the change, as suggested | |
| 08:00:40 | tkajinam | I've not created any bp for a while so lmk if I made something wrong ... | |
| 08:41:40 | gibi | tkajinam: good to see you around :) The BP looks good to me | |
| 08:42:58 | gibi | bauzas: ^^ do we need to wait for the next nova meeting to approve that or we already agreed about the feature and this is just paperwork? | |
| 08:44:34 | tkajinam | gibi, hey. good morning and hope everything is good with you. thanks for checking the bp :-D | |
| 08:49:35 | bauzas | lgtm, I can stamp the paperwork | |
| 08:51:20 | bauzas | tkajinam: gibi: sean-k-mooney: bp approved as specless, good to go for reviews | |
| 08:56:48 | gibi | bauzas: cool | |
| 08:57:09 | gibi | tkajinam: yeah all good here. Hope all good on your side too | |
| 08:57:38 | bauzas | tkajinam: btw. saw your email on tooz | |
| 08:58:04 | bauzas | fwiw, I agree with the concerns, we rather need tooz to continue to verify the older API | |
| 08:58:56 | bauzas | even if we say to our operators that they should first upgrade their environment to the last minor .y version before SLURP upgrading, some of them could not do that for tooz | |
| 08:59:05 | bauzas | given it's a library | |
| 08:59:46 | SvenKieske | anybody has seen this qemu issue anywhere? https://gitlab.com/qemu-project/qemu/-/issues/1069 | |
| 09:08:31 | tkajinam | gibi, all good on my side as well :-) | |
| 09:09:16 | tkajinam | bauzas, thanks for the approval ! | |
| 09:13:57 | tkajinam | bauzas, hmm the limitation caused by hard-coded api version can't be fixed in older tooz unfortunately (because of the fact tooz is branchless) though the proposed change should ease the pain caused by etcd versions. | |
| 09:14:35 | tkajinam | bauzas, and I agree that we need tooz to continue to verify the older API. The proposed API detection mechanism should work for older tooz but we probably have to have a few functional tests to verify it with older etcd | |
| 09:15:07 | bauzas | to be clear, grenade and devstack are just coal canaries | |
| 09:15:35 | bauzas | the problem is the SLURP upgrade, which implies that you don't need to lockstep both the openstack upgrade and the OS upgrade | |
| 09:15:46 | bauzas | well, that's not a problem, that's rather a tenet | |
| 09:16:08 | bauzas | operators aren't forced to upgrade their OSes during openstack upgrade itself | |
| 09:16:37 | bauzas | that's why we have PTIs that continue to support old OS releases during 2 SLURP cadences | |
| 09:16:37 | tkajinam | I agree | |
| 09:17:39 | tkajinam | yes | |
| 09:18:30 | bauzas | the problem is that tooz is branchless | |
| 09:18:59 | bauzas | but new tooz (which would be upgraded during the SLURP release) still needs to talk like the old tooz was doing, against an old etcd API | |
| 09:19:08 | bauzas | we don't need to backport anything | |
| 09:19:34 | bauzas | or ask the operators to minor-uprgade their libs before the SLURP upgrade | |
| 09:21:27 | gibi | bauzas: the SEV slot autodetection impl patch is fairly simple and I'm +2 on it, so I think it is an easy win :) | |
| 09:21:44 | tkajinam | I'm not too sure how many users may maintain tooz independently from OpenStack. usually it's bundled to OpenStack in distros for example. (The tooz package comes from UCA or RDO afair) | |
| 09:21:45 | tkajinam | but | |
| 09:22:38 | tkajinam | bauzas, I think your concern should be cleared by the change I proposed to tooz. the old tooz was able to talk with old etcd without api version override. now with the change new tooz is able to talk with old etcd without api version override so the default behavior is same before/after updating tooz | |
| 09:23:29 | bauzas | ++ | |
| 09:24:46 | tkajinam | gibi, thanks :-D | |
| 09:33:12 | opendevreview | Haidong Pang proposed openstack/nova master: Corrected allocation deletion error during live migration. https://review.opendev.org/c/openstack/nova/+/901721 | |
| 10:36:30 | sean-k-mooney | tkajinam: i approved the patch gibi thanks for reviewing | |
| 10:38:22 | sean-k-mooney | tkajinam: specifically https://review.opendev.org/c/openstack/nova/+/899381 thanks for paying donw that technial debt | |
| 11:52:30 | dvo-plv | sean-k-mooney, gibi Do you have a time today to review this proposal ? https://review.opendev.org/c/openstack/nova-specs/+/895924 | |
| 11:52:35 | dvo-plv | https://review.opendev.org/c/openstack/nova/+/876075 | |
| 12:18:36 | sean-k-mooney | i readded my +2 to the spec | |
| 12:18:44 | dvo-plv | thanks | |
| 12:18:51 | sean-k-mooney | im not sure ill have time to review the code today but ill see how my day goes | |
| 12:19:19 | sean-k-mooney | if i dont get to it today feel free to ping me on monday (im on pto tomorrow) | |
| 12:19:47 | sean-k-mooney | i was largely happy with the implemation before so if you have adress gibis previous comments in the nova patch | |
| 12:20:10 | sean-k-mooney | then its likely that nova patch is more or less ready to merge unless we see anything else on this revions | |
| 12:22:22 | dvo-plv | sure, thanks | |
| 17:01:37 | auniyal6 | Hi dansmith, just a reminderto review https://review.opendev.org/c/openstack/nova/+/865336 | |
| 17:03:22 | auniyal6 | you said earlier "will chat with sean-k-mooney about it when he's back before I review/approve" | |
| 17:04:05 | auniyal6 | this only walaby is pending https://review.opendev.org/q/topic:%22bug/1970467%22 | |
| 18:13:27 | opendevreview | Merged openstack/nova master: Detect maximum number of SEV guests automatically https://review.opendev.org/c/openstack/nova/+/899381 | |
| 18:21:35 | sean-k-mooney | artom: Uggla_ if you get around to revisiting https://review.opendev.org/c/openstack/nova/+/877773 i left a -1 and some chagnes that would be required fro that to be backporable. | |
| 18:31:21 | artom | sean-k-mooney, you're insane :) | |
| 18:31:29 | artom | I mean that in the best way possible | |
| 18:32:45 | artom | At least you wrapped it in a @property | |
| #openstack-nova - 2023-11-24 | |||
| 04:17:26 | opendevreview | Rajesh Tailor proposed openstack/nova master: Add upgrade status check for duplicate cell names https://review.opendev.org/c/openstack/nova/+/901810 | |
| 04:50:31 | opendevreview | Rajesh Tailor proposed openstack/nova master: Handle InstanceExists exception for duplicate instance https://review.opendev.org/c/openstack/nova/+/860938 | |
| 08:00:41 | opendevreview | Rajesh Tailor proposed openstack/nova master: Add retry on attachment_update https://review.opendev.org/c/openstack/nova/+/901815 | |
| 08:04:44 | opendevreview | Rajesh Tailor proposed openstack/nova master: Add retry on attachment_update https://review.opendev.org/c/openstack/nova/+/901815 | |
| 08:10:49 | opendevreview | Haidong Pang proposed openstack/nova master: Catch MessagingTimeout during evacuation https://review.opendev.org/c/openstack/nova/+/901817 | |
| 10:01:14 | opendevreview | Amit Uniyal proposed openstack/nova master: enforce remote sonsole shutdown https://review.opendev.org/c/openstack/nova/+/901824 | |
| 10:22:46 | bauzas | gibi: thanks for having commented https://review.opendev.org/c/openstack/nova/+/899625 | |
| 10:22:58 | bauzas | good point, I haven't verified about providing *,* | |
| 13:44:53 | bauzas | gibi: sean-k-mooney: got a sec for discussing about https://review.opendev.org/c/openstack/nova/+/899625/ ? | |
| 13:46:44 | bauzas | if not, no worries | |
| 13:46:51 | bauzas | lemme explain what I'll do | |
| 13:48:28 | bauzas | first, I'll work on pas-ha[m] patch https://review.opendev.org/c/openstack/nova/+/899406 for having it as a dependency for https://review.opendev.org/c/openstack/nova/+/899625/ | |
| 13:49:10 | bauzas | secondly, I'll split my own patch in two, one for let's make device_addresses to be None | |
| 13:49:24 | bauzas | (instead of a wildcard) | |
| 13:49:42 | bauzas | and then, the third change will be https://review.opendev.org/c/openstack/nova/+/899625/ without the wildcard | |
| 13:49:48 | bauzas | pas-ha[m]: are you around? | |
| 14:12:14 | bauzas | pas-ha[m]: fwiw, I'm gonna add a few UTs | |
| 14:12:18 | bauzas | to your patch | |
| 14:18:49 | pas-ha[m] | bauzas: hi, sure | |
| 14:20:12 | bauzas | on it already, shall be quick hopefully | |
| 14:20:30 | bauzas | I feel sad, I just saw https://review.opendev.org/c/openstack/nova/+/858012 | |
| 14:21:05 | bauzas | people discovered the bug with SRIOV VFs like one year ago, but due to a difficult bug report and no way to reproduce it, I skipped it | |
| 14:44:10 | gibi | bauzas: sean-k-mooney is out today | |
| 14:46:09 | bauzas | ack | |
| 14:46:55 | bauzas | my point is that I want to split the fact that we modify the option from the other bugfix, which is how to not use the other inventories | |
| 14:47:07 | gibi | make sense | |
| 14:48:20 | bauzas | and then we could discuss whether we prefer to have a wildcard or just not using device_addresses | |
| 14:48:35 | bauzas | IMHO, after thinking about it, I prefer the latter | |
| 14:49:01 | gibi | not using device_addresses simplifies the config parsing | |
| 14:49:26 | gibi | it make the meaning of the config a bit less obvious | |
| 14:49:35 | gibi | but we can document that | |
| 14:50:21 | gibi | is the reason of wildcarding to make the number of inventories dynamic? | |
| 14:51:05 | bauzas | no, just because it would be large to provide all of the VFs for example with a L2 | |
| 14:51:10 | bauzas | which has 32 of them :) | |
| 14:51:43 | gibi | ahh | |
| 14:51:45 | bauzas | this is simplier to say 'let's just let nova to find the needed VFs' | |
| 14:52:45 | gibi | but it has a side effect that if the number of VF changes nova will dynamically pick up the change | |
| 14:54:05 | bauzas | well | |
| 14:54:13 | bauzas | it's the same if they change the GPU | |
| 14:54:37 | bauzas | the VFs shouldn't change unless the GPU is changed | |
| 14:54:54 | bauzas | and fwiw, for that, the operator needs to first to either delete or shelve the instances | |
| 14:55:04 | bauzas | because of the allocations | |
| 14:55:05 | gibi | OK so the number of VFs is constant for a given pGPU | |
| 14:55:12 | bauzas | yeah | |