| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-02-15 | |||
| 14:33:44 | sean-k-mooney | i.e. i would like to moderenize some things and pay down tech debt | |
| 14:34:08 | sean-k-mooney | like i really want to see the SQLA2.0 stuff done in manilla so we can move to it | |
| 14:34:28 | sean-k-mooney | or get the wsgi/pyproject.yaml stuff doen | |
| 14:34:34 | sean-k-mooney | just time... | |
| 14:35:16 | sean-k-mooney | JayF: thanks for responding :) | |
| 14:36:53 | JayF | I have a friend who works on a major python library who always says (joking) that they're about 100 developers working on infrastructure across all technology. | |
| 14:37:28 | JayF | Finding the quote from that paper about OSS contribution that said 97% of value was created by 5% of people... It's weird to see the gist of your validated by research | |
| 14:37:42 | JayF | **your joke | |
| 14:38:06 | sean-k-mooney | the best jokes are based in reality... | |
| 14:40:31 | sean-k-mooney | i was chatting to one of the developer workign on stading up the infra for centos 10 stream yeasterday and they actully suggested that instead of using centos stream a a rhel next proxy we should be using https://docs.fedoraproject.org/en-US/eln/ | |
| 14:41:05 | sean-k-mooney | apprenetly fedora eln is what facebook and amazone use to build adn test there rhel deritivtes | |
| 14:42:39 | sean-k-mooney | if we were usign fedroa eln + rocky/almalinux we would ahve better proxies for btoh rhel next and rhel current | |
| 14:42:48 | sean-k-mooney | then useing stream gives us today | |
| 15:35:11 | opendevreview | Doug Szumski proposed openstack/nova master: Revert "[libvirt] Live migration fails when config_drive_format=iso9660" https://review.opendev.org/c/openstack/nova/+/909122 | |
| 15:45:00 | opendevreview | Doug Szumski proposed openstack/nova master: Revert "[libvirt] Live migration fails when config_drive_format=iso9660" https://review.opendev.org/c/openstack/nova/+/909122 | |
| 15:56:19 | dougszu | As promised sean-k-mooney ^. It's entirely clear to me yet. Will keep digging. | |
| 15:56:23 | dougszu | *not | |
| 17:15:10 | dansmith | bauzas: I thought you said you were going to remove the dict and use the guest XMLs to determine persistence in this: https://review.opendev.org/c/openstack/nova/+/904209 | |
| 17:15:22 | dansmith | did I misunderstand or are we still waiting for that revision/ | |
| 17:26:00 | mnaser | I'd appreciate reviews on https://review.opendev.org/c/openstack/nova/+/909082 + https://review.opendev.org/c/openstack/nova/+/909086 -- we'll need to cherry-pick it a bit further down so b enice to merge those in | |
| 18:00:54 | bauzas | dansmith : I'm not super opinionated about that, I eventually thought that it wouldn't be a problem if we reserve the mdevs with the dict | |
| 18:01:25 | dansmith | using the xmls seems better to me, but I know it's more work | |
| 18:01:35 | dansmith | I'm mostly asking because I was expecting to see that change and haven't | |
| 18:01:53 | bauzas | Well, we already look at the XMLs | |
| 18:02:12 | bauzas | So it should be automatically find the paused guests | |
| 18:02:28 | bauzas | So the dict shouldn't be needed | |
| 18:03:22 | bauzas | but again, in case libvirt would change it, I'm not sure it would continue to work | |
| 18:03:34 | bauzas | I can test it if you want | |
| 18:04:05 | dansmith | I think it would be better to not have a thing that can get out of sync, so if it's reasonable to PoC it, I think that's worth it | |
| 18:18:07 | sean-k-mooney | with that said i get dans concern about it getting out of sync | |
| 18:18:07 | sean-k-mooney | i have said this in the past that i woudl not have merged the orginal vgpu code that used the xmls to track what mdevs where in use | |
| 18:18:07 | sean-k-mooney | dansmith: bauzas so im very hesitent to addign even more reliance on the xmls | |
| 18:18:07 | sean-k-mooney | mnaser: i tought you might be interested in those | |
| 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 | |