Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-12-19
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 bauzas #endmeeting
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 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2023/nova.2023-12-19-16.00.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 Log: https://meetings.opendev.org/meetings/nova/2023/nova.2023-12-19-16.00.log.html
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
17:22:57 bauzas sean-k-mooney: noted, will change too
17:24:35 bauzas damiandabrowski: sean-k-mooney: the path that's checking whether we should pin to an AZ for a volume https://github.com/openstack/nova/blob/d28a55959e50b472e181809b919e11a896f989e3/nova/compute/api.py#L1268
17:24:45 JayF bauzas: others; feedback from dtantsur in #openstack-ironic leads me to revise the ironic guest metadata spec to remove flavor since flavor name is volatile and can change while the instance is provisioned; in general can you consider us sending *less* fields to Ironic than listed in that spec an implementation detail?
17:25:05 bauzas JayF: yup, no worries
17:25:13 sean-k-mooney JayF: that why i was saying we should use the falvor uuid
17:25:13 bauzas we said all that meat is specless
17:25:25 JayF ack
17:25:35 JayF sean-k-mooney: that's not in the libvirt one today, fwiw
17:25:35 bauzas this is an implementation detail that will reviewed at time
17:25:52 sean-k-mooney JayF: yep i know thats an oversight i wanted to fix
17:26:07 sean-k-mooney we have access to it we are just not storing it right now
17:26:28 sean-k-mooney JayF: flavors are imuntable (extra_spec are not)
17:26:28 JayF ++ sounds good, we can easily do that with the centralization of that code
17:27:10 sean-k-mooney you can recarete a flavor with the same name as previously deleted one but you cant specify a uuid
17:28:20 sean-k-mooney JayF: with regards to updating the bluepint lets add a doc in the refernce/continbutor section
17:28:22 dtantsur JayF: I assume the flavor uuid only fixes a half of the problem: the flavor can deleted or (?changed?)
17:28:24 sean-k-mooney to detail how this works
17:28:50 sean-k-mooney dtantsur: it can be but that does not make the info useless
17:29:10 dtantsur sean-k-mooney: but isn't it the reason why nova provides neither name nor uuid in the newer API versions?
17:29:15 JayF sean-k-mooney: I don't know what that means?
17:29:42 sean-k-mooney JayF: while the flavor exist the uuid is useful for operator s to correalte nodes
17:30:27 dtantsur yeah, I don't see flavor UUID in https://docs.openstack.org/api-ref/compute/#show-server-details
17:30:29 JayF sean-k-mooney: the "doc in reference/contributor section" bit is what I don't understand
17:30:41 sean-k-mooney dtantsur: we provide flavor.original_name i server show
17:30:52 JayF If the flavor uuid/name isn't in Nova's API, it's not super useful in Ironic's API tbh
17:31:15 JayF and given there's a price to putting keys in that json field, if it's not cross-referenceable, I'd rather not send it
17:31:18 damiandabrowski bauzas: thanks, then something is off...I'll try to gather more details
17:31:24 sean-k-mooney JayF: it is in the api up to version 2.46
17:31:39 dtantsur when you say flavor UUID, you mean its numerical ID?
17:31:46 dtantsur "The ID of the flavor. While people often make this look like an int, this is really a string."?
17:32:07 sean-k-mooney JayF: in 2.47 we addded flavor.original_name and remove flavor.name and flavor.id because they can be deleted but we cache a copy of hte flavor in the isntance_extra table when its created
17:32:32 JayF sean-k-mooney: so it sounds like that is probably information better left for the operator to lookup in nova api
17:32:46 sean-k-mooney dtantsur: flavor.id is a string filed that can be an int or any other sting. we generate a uuid if you dont provide one
17:33:18 dtantsur I"m curious, why don't you publish id yourself then?
17:33:26 dtantsur it's weird to add something to ironic that nova decided to remove
17:33:29 opendevreview Merged openstack/nova stable/zed: Translate VF network capabilities to port binding https://review.opendev.org/c/openstack/nova/+/899229
17:33:33 sean-k-mooney we did and im not sure why we did keep it
17:33:44 sean-k-mooney but you can still get it usign the old microverion
17:33:58 sean-k-mooney im not sure why we dont have flavor.original_id
17:34:13 dtantsur yeah, this ^^^
17:34:23 opendevreview Sylvain Bauza proposed openstack/nova-specs master: Proposes mdev live-migration support in libvirt https://review.opendev.org/c/openstack/nova-specs/+/900636
17:34:41 bauzas sean-k-mooney: gibi: updated based on sean-k-mooney's nice improvments
17:34:49 JayF Either way, it's clear the arrows of the "latest" version of the API is that this information is best looked up and kept in nova, if it's not a first class API object in Nova that's guaranteed to be there and/or Ironic is not going to cache the flavor like nova does
17:35:07 JayF this was going to be an easy win; it's not; so punt it and keep the metadata that is the easy wins IMO
17:35:29 JayF our API already has enough places with weird corners, this sounds like an easy place to avoid making another one
17:35:30 sean-k-mooney so looks like it was changed in pike https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#id43 so there should be a spec
17:36:54 sean-k-mooney https://specs.openstack.org/openstack/nova-specs/specs/pike/implemented/instance-flavor-api.html#proposed-change it jsut says it could be stale but i kind of think that was a mistake

Earlier   Later