| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-12-19 | |||
| 16:32:35 | sean-k-mooney | i think yes | |
| 16:32:56 | bauzas | so, I'm off from Christmas to Jan 8 | |
| 16:33:10 | bauzas | (Jan 8 not included, tbc) | |
| 16:33:25 | gibi | +1 on skipping | |
| 16:33:29 | gibi | I'm back on the 15th | |
| 16:33:31 | elodilles | +1 from me, too | |
| 16:33:48 | bauzas | anyone having concerns and wanting to discuss the next day after Jan 1 ? :D | |
| 16:34:17 | bauzas | looks not | |
| 16:34:42 | bauzas | #agreed Next two nova meetings (Dec 26 and Jan 2) will be SKIPPED. Next meeting will be Jan 9 | |
| 16:34:55 | bauzas | #action bauzas to communicate this over ML | |
| 16:35:05 | bauzas | okay | |
| 16:35:11 | bauzas | so, we have another item | |
| 16:35:18 | bauzas | that we already discussed last week | |
| 16:35:24 | bauzas | (JayF/johnthetubaguy) Specless blueprint for ironic guest metadata | |
| 16:35:28 | bauzas | https://blueprints.launchpad.net/nova/+spec/ironic-guest-metadata | |
| 16:35:33 | JayF | I've put a significant amount of detail in this since last week | |
| 16:35:39 | bauzas | JayF: fancy taking the baton again ? | |
| 16:35:42 | bauzas | cool | |
| 16:35:43 | JayF | I'm happy to discuss here, or async in the blueprint/mailing list/etc | |
| 16:36:11 | JayF | This is mostly based on conversations with sean-k-mooney, especially the part about generalizing the libvirt code | |
| 16:36:55 | sean-k-mooney | just readign it now | |
| 16:37:10 | bauzas | JayF: I just have one question | |
| 16:37:43 | JayF | I either have an answer or a clever deflection technique ;) | |
| 16:37:46 | bauzas | with a SLURP environment consisted of Caracal controllers, Caracal computes but also Antelope computes, how Ironic could use this ? | |
| 16:38:07 | JayF | Ironic is going to just look for the metadata provided by Nova in instnace_info | |
| 16:38:16 | sean-k-mooney | im not sure that will matter given this will be entrily in the driver | |
| 16:38:18 | JayF | if it's there; Ironic will add the lessee; if not, it won't | |
| 16:38:39 | JayF | if someone is migrating, they'll migrate *after* the upgrade is complete and because the migration script is additive only, it'll make the environment consistent | |
| 16:39:00 | sean-k-mooney | if the ironic compute are running antelope code it just wotn set that data | |
| 16:39:03 | bauzas | JayF: here, I just want to hear that you understand that the metadata will be optional, at least until we upgrade to 2024.2 | |
| 16:39:11 | sean-k-mooney | if its upgraded it can check the ironic api version if needed | |
| 16:39:22 | JayF | Absolutely; 100%, ironic will opportunistically use that metadata if it exists, we will not make a hard dependency on it | |
| 16:39:54 | JayF | it'd be an API break for us to do anything else | |
| 16:40:03 | sean-k-mooney | the ironic script that will be created for backfilling can also be used to reconsile everythign after the upgrade is fully done | |
| 16:40:22 | opendevreview | Stephen Finucane proposed openstack/nova master: Resolve mypy error https://review.opendev.org/c/openstack/nova/+/903530 | |
| 16:40:23 | opendevreview | Stephen Finucane proposed openstack/nova master: pre-commit: Add mypy https://review.opendev.org/c/openstack/nova/+/896228 | |
| 16:40:23 | opendevreview | Stephen Finucane proposed openstack/nova master: tox: Use pre-commit for pep8 target https://review.opendev.org/c/openstack/nova/+/896227 | |
| 16:40:24 | opendevreview | Stephen Finucane proposed openstack/nova master: pre-commit: Bump linter versions https://review.opendev.org/c/openstack/nova/+/903749 | |
| 16:40:36 | bauzas | JayF: then I'm cool | |
| 16:40:41 | JayF | woo | |
| 16:40:49 | sean-k-mooney | i think im oke with moving forward with this as a specless bluepint and movign the dicussion to the implementaion | |
| 16:40:51 | bauzas | from a nova pov, this is just a small thing | |
| 16:41:12 | JayF | That's sorta how I feel about it too, but it's hard for me to tell :) | |
| 16:41:18 | bauzas | but again, I don't want Ironic to have a bug because we continue to support Antelope computes, that's it :) | |
| 16:41:40 | bauzas | if the plan is already sorted, then yay, sounds specless | |
| 16:41:53 | bauzas | anyone concerned by any design problem ? | |
| 16:42:10 | bauzas | anyone thinking of some nit that would need to be discussed ? | |
| 16:42:29 | bauzas | apparently no | |
| 16:42:36 | bauzas | so, | |
| 16:42:53 | JayF | I'll note Ironic team discussed this at PTG; this reflects that discussion. I'll run it by our cores as well, don't expect any contention but I'll make another round trip here if there's any change. | |
| 16:43:07 | bauzas | #agreed https://blueprints.launchpad.net/nova/+spec/ironic-guest-metadata to be approved as a specless blueprint for 2024.1 timeframe | |
| 16:43:54 | JayF | Thank you o/ | |
| 16:44:22 | bauzas | I already did the paperwork stamping | |
| 16:44:41 | bauzas | I guess we're done with the meeting | |
| 16:44:51 | bauzas | I don't see anything else in the agenda | |
| 16:44:55 | fwiesel | Thanks everyone and happy holidays | |
| 16:44:56 | bauzas | so, anything anyone ? | |
| 16:45:03 | gibi | have a nice time off folks! | |
| 16:45:26 | elodilles | happy holidays o/ | |
| 16:45:28 | bauzas | yeah, happy holidays to all of you and for those who take time off, have a good one :) | |
| 16:45:40 | bauzas | see you all next year | |
| 16:45:50 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2023/nova.2023-12-19-16.00.log.html | |
| 16:45:50 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2023/nova.2023-12-19-16.00.txt | |
| 16:45:50 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2023/nova.2023-12-19-16.00.html | |
| 16:45:50 | opendevmeet | Meeting ended Tue Dec 19 16:45:50 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 16:45:50 | bauzas | #endmeeting | |
| 16:55:25 | artom | bauzas, sorry, was AFK, yep, can look at bugs | |
| 16:58:08 | bauzas | artom: thanks and again, as a reminder, low prio, stretch good at most | |
| 16:58:12 | bauzas | goal* | |
| 16:58:19 | bauzas | don't feel obliged. | |
| 16:58:22 | artom | Well don't say that :) | |
| 16:59:37 | bauzas | I'm just clear on the fact I can't force anyone to do upstream work if they are not recognized for that | |
| 17:03:25 | sean-k-mooney | bauzas: https://review.opendev.org/c/openstack/nova-specs/+/900636 +1 can you review my comments | |
| 17:04:16 | damiandabrowski | Unfortunately, even I have cinder.cross_az_attach=False, scheduler moves VM to the other AZ during migrate/resize which breaks it. | |
| 17:04:45 | damiandabrowski | ^ it was not intended, please let me send messages in a correct order :D | |
| 17:07:13 | damiandabrowski | Hey! I want to deploy multi-AZ environment(shared network, separate ceph cluster in each AZ, no default_schedule_zone, no explicit AZ provided when creating VM, Zed Release). | |
| 17:07:20 | damiandabrowski | Unfortunately, even I have cinder.cross_az_attach=False, scheduler moves VM to the other AZ during migrate/resize which breaks it. | |
| 17:07:25 | damiandabrowski | In documentation, I found the following statement so I guess it's an expected behavior: "If the server was not created in a specific zone then it is free to be moved to other zones, i.e. the AvailabilityZoneFilter is a no-op." | |
| 17:07:30 | damiandabrowski | Is there any way to prevent changing AZs during resize/migrate? | |
| 17:08:30 | sean-k-mooney | damiandabrowski: if the vm was create before enabling that settign on both the comptues and contoler it wont have updated the request spec with the az | |
| 17:09:00 | sean-k-mooney | damiandabrowski: live migration ebtween AZ is expected to work in genreal yes | |
| 17:09:16 | sean-k-mooney | damiandabrowski: my guess is if you check the request spec of the vm in question | |
| 17:09:24 | sean-k-mooney | it will not have an az specified | |
| 17:09:39 | sean-k-mooney | only the az in the request spec is considerd when schduling | |
| 17:10:17 | bauzas | sean-k-mooney: you're right on your first comment, we could return the mdev values in one step by the claim https://github.com/openstack/nova/blob/45e2349408dd3b385217066a3c5a4c29d7bdd3a0/nova/compute/manager.py#L8550 | |
| 17:10:25 | bauzas | that's a good call | |
| 17:16:29 | sean-k-mooney | the second change is so we know which uuid mapps to which type so that we can avoid changing the pci adress of the vgpus if we every have more then one in vm | |
| 17:16:53 | sean-k-mooney | that way i want to map the source mdev to the dest mdev that has the same type | |
| 17:19:27 | damiandabrowski | sean-k-mooney: thanks for reply. My test vm are created after setting cinder.cross_az_attach=False on controllers and computes. | |
| 17:19:51 | damiandabrowski | I guess nova.instance_extra is a place where I can find instance extra specs right? | |
| 17:19:54 | damiandabrowski | https://paste.openstack.org/show/bXZgVyObqHQfn6yAVdET/ | |
| 17:20:02 | sean-k-mooney | bauzas: ^ you are more familar with that code path. | |
| 17:20:09 | sean-k-mooney | damiandabrowski: yes but this is not an extra spec | |
| 17:20:32 | sean-k-mooney | the request_spec is an object in the api db | |
| 17:21:51 | damiandabrowski | ahh my bad, thanks! | |
| 17:21:52 | damiandabrowski | https://paste.openstack.org/raw/bUwKEZg6FsylqJj4mDBi/ | |
| 17:21:57 | damiandabrowski | "availability_zone": null | |
| 17:22:11 | bauzas | strange | |
| 17:22:31 | bauzas | if you had cross_az_attach=False, then the reqspec should have been modified | |
| 17:22:40 | bauzas | by pinning to the volume AZ | |