| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-02-15 | |||
| 18:20:31 | sean-k-mooney | bauzas: the dict is needed because the pasued guest does not exist in pre-live-migrate | |
| 18:20:42 | sean-k-mooney | its only created by libvirt when we start the migration | |
| 18:21:08 | sean-k-mooney | so if we dont have the dict pre precreate the domain in pre live migrate on the dest we woudl have a rcace | |
| 18:21:39 | sean-k-mooney | so to remove the dict you need to add creating a domin | |
| 18:21:48 | sean-k-mooney | you shoudl not create a paused doamin however | |
| 18:22:08 | sean-k-mooney | jsut define it and create the approate cleanup codded for revert | |
| 18:22:49 | sean-k-mooney | just beause i strongly dislike what we do with the xml does not mean im -2 on replacing the dict with pre defineing a domian to reserve the mdev | |
| 18:22:57 | bauzas | sean-k-mooney: the target is automatically created by libvirt | |
| 18:23:09 | bauzas | and then paused | |
| 18:23:13 | sean-k-mooney | yes but only wehn we call migrate2URL | |
| 18:23:15 | bauzas | don't ask me how | |
| 18:23:23 | bauzas | sean-k-mooney: yup frow what I saw | |
| 18:23:26 | sean-k-mooney | it wont exist in pre-live migrate | |
| 18:23:30 | bauzas | indeed | |
| 18:23:34 | sean-k-mooney | so you cant jsut remove the dict | |
| 18:23:40 | sean-k-mooney | without intoducting a race condition | |
| 18:24:00 | bauzas | okay, so your preference is to keep the dict ? fine by me, as I said I'm not opiniated | |
| 18:24:06 | bauzas | there are pros and cons | |
| 18:24:07 | sean-k-mooney | if you want to remove the dict based on dansmith's feedback then you need to define the domain on the dest instead | |
| 18:24:31 | bauzas | not sure it may work | |
| 18:24:37 | sean-k-mooney | im ok with using a domian xml to reserve it as long as we evenutally stop using the xmls for this in the long term | |
| 18:24:48 | sean-k-mooney | bauzas: you can defien a domain without starting it | |
| 18:24:50 | bauzas | maybe the best would be to persist the mdevs in some internal state | |
| 18:24:58 | sean-k-mooney | yes it would | |
| 18:25:03 | sean-k-mooney | but out of scope of this cycle | |
| 18:25:21 | bauzas | so, if dansmith accepts, let's keep it straight as it is | |
| 18:25:43 | sean-k-mooney | we could also tack on the use of a doamin as a patch on the end | |
| 18:26:04 | sean-k-mooney | again depending on dansmith's prefernce to derisk things | |
| 18:26:14 | bauzas | sean-k-mooney: we would need to delete the domain as soon as we call migrate | |
| 18:26:26 | sean-k-mooney | no we would not | |
| 18:26:30 | sean-k-mooney | libvirt shoudl update it | |
| 18:26:31 | bauzas | and there could be residues too | |
| 18:26:57 | sean-k-mooney | there would be yes which is why i said you would have to update revert | |
| 18:26:59 | dansmith | I don't want to push us to define the domain before we migrate, I just thought bauzas said it was already there by the time we needed to account for the things | |
| 18:27:05 | bauzas | honestly, the more I think is to keep the existing | |
| 18:27:30 | sean-k-mooney | dansmith: its not we are creating the mdevs and returning the uuid in prelive migrate | |
| 18:27:34 | bauzas | dansmith: sean-k-mooney had a concern if we were removing the patch as the domain is only created by libvirt once we call migrate | |
| 18:27:35 | dansmith | personally I don't like that we're keeping an in-memory dict which could get out of sync if we have an mq blip, where restarting compute will just make it work again and for which the operator has basically no visibility | |
| 18:27:37 | dansmith | the logs help, but... | |
| 18:27:39 | sean-k-mooney | then we generate the domain on the souce after that | |
| 18:28:18 | bauzas | there is no easy path here | |
| 18:28:26 | bauzas | as I said, pros and cons for each of the solutions | |
| 18:28:38 | sean-k-mooney | dansmith: ya i would prefer to be trackign mdev in novas db. but i would also prefer to do that next cycle | |
| 18:28:55 | dansmith | yeah clearly not something we can do in the short term | |
| 18:28:59 | bauzas | I'm just saying that a dict that would be emptied as soon as we restart the compute is probably the simpliest approach | |
| 18:29:09 | sean-k-mooney | yep | |
| 18:29:22 | dansmith | bauzas: yeah it just sucks to make it fragile and restarts to fix things | |
| 18:29:27 | dansmith | but sounds like that's the option for now | |
| 18:29:37 | bauzas | dansmith: only if the MQ blip happens on abort, right? | |
| 18:29:52 | bauzas | that's only when you have a residue | |
| 18:30:11 | dansmith | bauzas: any time between when we record it and would commit/clean | |
| 18:30:34 | dansmith | just saying, it feels fragile, like I've _been_ saying, but I know the argument for it | |
| 18:30:35 | bauzas | we record it when we pre-livemigrate | |
| 18:30:55 | bauzas | then we delete it as soon as the migration is complete or aborted | |
| 18:31:03 | dansmith | I understand | |
| 18:31:24 | bauzas | if we have a MQ blip in between, then the live-migration could be impacted as well | |
| 18:31:36 | bauzas | I said "could" because the migration could be run on different NIC | |
| 18:32:30 | bauzas | but what's important is that the message saying "I'm done, please remove it" or "I was aborted, please remove it" needs to arrive | |
| 18:33:06 | bauzas | dansmith: I think I proposed a periodic, I'll try to add it on top of my series | |
| 18:37:05 | dansmith | ack | |
| 18:37:49 | bauzas | but I think we have some reconciliation methods in libvirt for the guests | |
| 18:37:59 | bauzas | (I'm sure, at least for the guest states) | |
| 18:46:41 | sean-k-mooney | bauzas: either add a new one or do this as part of update_avaiable_resouces | |
| 18:47:00 | sean-k-mooney | i dont think there are any other perodics that would make sense | |
| 18:47:24 | sean-k-mooney | update_avaiable_resouces takes a resouce tracker lock and already acocunts for migration ectra | |
| 18:47:56 | sean-k-mooney | so removign instances form the dict that are not on this host and dont have a migration assocated with the host would be ok i think | |
| #openstack-nova - 2024-02-16 | |||
| 06:31:02 | opendevreview | Takashi Kajinami proposed openstack/os-traits master: Add traits for TPM models https://review.opendev.org/c/openstack/os-traits/+/909107 | |
| 06:31:32 | opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Detect vtpm support by libvirt https://review.opendev.org/c/openstack/nova/+/908508 | |
| 06:51:59 | opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Report available TPM models https://review.opendev.org/c/openstack/nova/+/909183 | |
| 06:55:22 | opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Report available TPM models https://review.opendev.org/c/openstack/nova/+/909183 | |
| 07:42:18 | opendevreview | Rajesh Tailor proposed openstack/nova master: Add support for showing requested az in output https://review.opendev.org/c/openstack/nova/+/904568 | |
| 08:47:54 | opendevreview | Rajesh Tailor proposed openstack/nova master: Add support for showing requested az in output https://review.opendev.org/c/openstack/nova/+/904568 | |
| 09:10:35 | opendevreview | Takashi Kajinami proposed openstack/nova master: Drop unused parameter type validation method https://review.opendev.org/c/openstack/nova/+/909189 | |
| 09:35:40 | opendevreview | Takashi Kajinami proposed openstack/nova master: Cleanup logics to detect nova-compute older than Victoria https://review.opendev.org/c/openstack/nova/+/909190 | |
| 09:40:29 | opendevreview | Takashi Kajinami proposed openstack/nova master: Cleanup logics to detect nova-compute <= Victoria https://review.opendev.org/c/openstack/nova/+/909190 | |
| 09:46:42 | opendevreview | Takashi Kajinami proposed openstack/nova master: Cleanup logics to detect nova-compute <= Victoria https://review.opendev.org/c/openstack/nova/+/909190 | |
| 09:53:32 | opendevreview | Takashi Kajinami proposed openstack/nova master: Cleanup logics to detect nova-compute <= Victoria https://review.opendev.org/c/openstack/nova/+/909190 | |
| 09:53:33 | opendevreview | Takashi Kajinami proposed openstack/nova master: Cleanup logics to detect nova-compute <= Wallaby https://review.opendev.org/c/openstack/nova/+/909192 | |
| 10:17:25 | opendevreview | Takashi Kajinami proposed openstack/nova master: Cleanup logics to detect nova-compute <= Wallaby https://review.opendev.org/c/openstack/nova/+/909192 | |
| 14:16:08 | opendevreview | Takashi Kajinami proposed openstack/nova master: Cleanup logics to detect nova-compute <= Wallaby https://review.opendev.org/c/openstack/nova/+/909192 | |
| 14:33:32 | opendevreview | Takashi Kajinami proposed openstack/nova master: Cleanup logics to detect nova-compute <= Xena https://review.opendev.org/c/openstack/nova/+/909202 | |
| 14:37:26 | opendevreview | Artem Vasilyev proposed openstack/nova stable/zed: libvirt: stop enabling hyperv feature reenlightenment https://review.opendev.org/c/openstack/nova/+/909098 | |
| 14:41:54 | opendevreview | Takashi Kajinami proposed openstack/nova master: Cleanup logics to detect nova-compute <= Yoga https://review.opendev.org/c/openstack/nova/+/909204 | |
| 14:51:04 | opendevreview | Takashi Kajinami proposed openstack/nova master: Cleanup logics to detect nova-compute <= Xena https://review.opendev.org/c/openstack/nova/+/909202 | |
| 14:51:05 | opendevreview | Takashi Kajinami proposed openstack/nova master: Cleanup logics to detect nova-compute <= Yoga https://review.opendev.org/c/openstack/nova/+/909204 | |
| 14:57:57 | stephenfin | melwitt, bauzas: Mind hitting this small doc fixup? https://review.opendev.org/c/openstack/nova/+/903675/1/doc/source/user/security-groups.rst | |
| 15:05:17 | bauzas | dansmith: sean-k-mooney: you'll see a new revision for my patches without the periodic, but I'll add it on Monday | |
| 15:05:30 | dansmith | ack | |
| 15:06:08 | opendevreview | Sylvain Bauza proposed openstack/nova master: Reserve mdevs to return to the source https://review.opendev.org/c/openstack/nova/+/904209 | |
| 15:06:09 | opendevreview | Sylvain Bauza proposed openstack/nova master: Modify the mdevs in the migrate XML https://review.opendev.org/c/openstack/nova/+/904258 | |
| 15:18:32 | opendevreview | Takashi Kajinami proposed openstack/nova master: Drop logic for compute service version < 33 https://review.opendev.org/c/openstack/nova/+/909218 | |
| 15:19:28 | mnaser | small ping again for https://review.opendev.org/c/openstack/nova/+/909082 and https://review.opendev.org/c/openstack/nova/+/909086 (i need to work these back to zed so appreciate if we can get em in earlier :D) | |
| 15:21:07 | opendevreview | Takashi Kajinami proposed openstack/nova master: Drop unnecessary mocking of get_minimum_version_all_cells https://review.opendev.org/c/openstack/nova/+/909219 | |
| 15:23:47 | mnaser | thank you stephenfin ! :) | |
| 15:23:53 | greatgatsby_ | Hello. We've hit a bit of a snag and are trying to figure out how to work around it. After upgrading the kernel on some of our computes, they no longer have the xsaves kernel feature, which is preventing us from migrating VMs to the upgraded computes. Any suggestions greatly appreciated. | |
| 15:24:12 | opendevreview | Takashi Kajinami proposed openstack/nova master: Cleanup logics to detect nova-compute <= Zed https://review.opendev.org/c/openstack/nova/+/909220 | |
| 15:24:13 | mnaser | greatgatsby_: ah if i can tell you how many times we've been bit by this exact one. | |
| 15:24:28 | mnaser | i assume you are running ubuntu right | |
| 15:25:24 | greatgatsby_ | hahaha, at least we're not alone! We contemplating some crazy cups and ball game, but it's getting scary. Yes, upgrading from ubuntu 20.04 default kernel. | |
| 15:25:48 | mnaser | greatgatsby_: https://bugs.launchpad.net/nova/+bug/1903822 | |