| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-02-15 | |||
| 13:00:08 | sean-k-mooney | not that one specificaly jsut in general | |
| 13:00:26 | sean-k-mooney | so truning off all the windows enlightenments is really not a compeling choice | |
| 13:04:24 | sean-k-mooney | elodilles: https://bugs.launchpad.net/nova/+bug/2046549 is more shocking to me | |
| 13:05:05 | sean-k-mooney | elodilles: i would have expected operators to be screaming at use for breakign live migration with windows guests | |
| 13:05:32 | elodilles | :-o | |
| 13:06:01 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/904183 is the fix but that is still in ci | |
| 13:08:53 | elodilles | so that will be also backported together with the above fix i guess then | |
| 13:09:04 | sean-k-mooney | that would be the intent yes | |
| 13:09:09 | sean-k-mooney | they can be backported seperatly | |
| 13:09:34 | sean-k-mooney | but both are a high prioryt i think to backprot | |
| 13:10:09 | sean-k-mooney | i think that will be compelling ot operators to have espeiclly those who have not upgraded to antelope yet | |
| 13:16:03 | elodilles | yepp, probably the thing is that 'those' operators have noy yet upgraded (not even to 2023.1 Antelope :S) | |
| 13:21:29 | opendevreview | Merged openstack/nova master: libvirt: stop enabling hyperv feature reenlightenment https://review.opendev.org/c/openstack/nova/+/904183 | |
| 14:00:50 | sean-k-mooney | artom: ^ fyi that merged on master so you can start the backport of that too now | |
| 14:20:11 | opendevreview | Mohammed Naser proposed openstack/nova stable/2023.2: libvirt: stop enabling hyperv feature reenlightenment https://review.opendev.org/c/openstack/nova/+/909086 | |
| 14:31:06 | sean-k-mooney | JayF: for that its worth we have mypy in some files in nova | |
| 14:31:38 | sean-k-mooney | JayF: so its not all or nothing it can be added gradully | |
| 14:32:14 | JayF | I know, and I think it would be cool, but that email the point was more.. do something rather than telling other people to do something 😀 | |
| 14:32:15 | sean-k-mooney | when startging new files like for the healthcheck stuff i have inteionally starte with mypy enabeld | |
| 14:32:25 | sean-k-mooney | yep | |
| 14:32:43 | sean-k-mooney | i am kind of trying to stay out of that thread | |
| 14:32:57 | sean-k-mooney | partly because i have been burnt on tryign to do simiear things and i just dont have time right now | |
| 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 | |