Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2026-03-02
16:56:03 dansmith I think documenting it as a limitation now is obviously better than having it fail,
16:56:33 dansmith but it is also probably indicative of us using something as a PK that shouldn't be, and I also think there are probably legit reasons for doing this related to HA
16:57:23 dansmith IIRC, we had a todo to make the NICs identifiable by alias like the disks work I did,
16:57:29 gibi I tried to poke the downstream reporter about their use case doing this but so far I got nothing
16:57:31 dansmith which is probably what we _should_ be using instead of MAC right?
16:58:00 bauzas could we fail early with a good self-explaned exception ?
16:58:02 gibi yeah libvirt has aliases. I haven't checked if it fits to our live migration XML manipulation code to use that
16:59:24 gibi bauzas: today we fail here which is probably late https://github.com/openstack/nova/blob/264e868d4931595140260c0f655a10b525be38f7/nova/virt/libvirt/migration.py#L496-L500
16:59:33 gibi sorry not there
16:59:40 gibi that is the place of the root cause
16:59:51 gibi we fail at
16:59:52 bauzas I'm thinking of when creating the instance
16:59:52 gibi File "/usr/lib64/python3.9/site-packages/libvirt.py", line 2225, in migrateToURI3
17:00:30 gibi bauzas: that would open a can of worms, 1) pre-existing instance with duplicated MAC 2) interface attach
17:00:37 bauzas if you ask for two ports, can we quick get the MAC addresses already or do we need another roundtrip ? (please, I don't want this if so)
17:00:49 gibi if failing early is the goal then we should fail pre-live migration
17:01:01 bauzas yup, then yes
17:01:14 dansmith well,
17:01:24 bauzas either in the conductor check or later in compute pre-flighyt
17:01:38 dansmith I think if we're going to say it's not allowed, we should prevent it at instance spawn/interface attach right?
17:01:51 dansmith because in this case, a user can do something that prevents an admin from live migrating an instance
17:01:57 dansmith which is not a cool thing to find out later
17:02:11 bauzas then it should be when we attach a port ?
17:02:14 dansmith so if we say "not allowed" it probably needs to be enforced much earlier
17:02:41 dansmith but again, I feel like this is probably something we can/should fix (even if later) with the alias stuff like we did for disks and planned for nics
17:03:22 bauzas right
17:03:32 gibi OK, if preventing it needs a bunch of code then maybe fixing it is comparable complexity (I was on the side of doccing it)
17:03:37 dansmith the disk stuff has fallen out of my brain a bit, but seems like we could use the port uuid as the alias and then we'd be able to match up the port and interface in that code, right?
17:04:00 dansmith gibi: well, I think documenting it also documents "how to prevent your operator from moving your instance around" :)
17:04:02 gibi dansmith: right port uuid is unique in openstack, nic alias is unique in the VM
17:04:08 dansmith yeah
17:05:04 gibi OK I will summarize this discussion back to the bug
17:05:29 gibi I got enough feedback that a simple doc patch will not be enough :)
17:05:57 gibi thanks
17:06:06 dansmith sorry gibi :/
17:06:10 Uggla gibi thanks to you explaining this.
17:06:47 Uggla We are already overtime, so time to close for this week.
17:06:57 cw0306-lee[m] Hi! I have a question.
17:07:01 gibi dansmith: no worries :)
17:07:16 Uggla cw0306-lee[m] last minute question, please go ahead
17:07:53 cw0306-lee[m] I tried to fix bug and added it to etherpad proposed bugfixes, will they be reviewed in order?
17:08:55 Uggla cw0306-lee[m] we will try. There is no specific order though, really depend on prio and reviewer bandwith.
17:09:19 cw0306-lee[m] Uggla: Thank you!
17:09:21 Uggla readiness too
17:10:21 Uggla ok so now time to close, thanks for joining this meeting. Have a nice day/evening and see you next week.
17:10:29 Uggla #endmeeting
17:10:29 opendevmeet Meeting ended Mon Mar 2 17:10:29 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
17:10:29 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2026/nova.2026-03-02-16.00.html
17:10:29 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2026/nova.2026-03-02-16.00.txt
17:10:29 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2026/nova.2026-03-02-16.00.log.html
17:10:33 gibi thanks Uggla
17:10:36 elodilles thanks o/
17:11:05 lajoskatona o/
17:11:09 Uggla gibi thanks to you, we have one more bug triaged !
17:12:22 tkajinam gmaan, regarding that novaclient tests update, do you know any stestr magic to avoid specific tests from being executed concurrently ?
17:12:25 tkajinam https://opendev.org/openstack/python-novaclient/src/branch/master/novaclient/tests/functional/v2/test_quota_classes.py#L79-L107
17:13:14 tkajinam the problem is that there are few tests accessing quota-class and if we use only the default one then we should refactor these to avoid conflicts among these
17:15:06 tkajinam I'll look into that tomorrow but the test update looks tricky for me now
17:18:53 sean-k-mooney tkajinam: for what its worth even in queens we have notes stating that only the default classs is supproted by nova
17:18:55 sean-k-mooney https://docs.openstack.org/nova/queens/admin/quotas.html#to-update-quota-values-for-an-existing-project
17:21:16 sean-k-mooney https://that.guru/blog/quotas-in-openstack/#quota-classes looking at the history the supprot for this was ripped out in ocata and there was never eally any intree supprot
17:21:57 gmaan tkajinam: for quota concurrent tests, I think you can use LockFixture like tempest is doing https://github.com/search?q=repo%3Aopenstack%2Ftempest%20compute_quotas&type=code
17:23:14 gmaan doing it via stestr also possible but that will be more complicated of grouping them and running in serial mode
17:25:45 sean-k-mooney ya porting the serial decorator is one approch
17:39:22 opendevreview Dominik proposed openstack/nova-specs master: Repurpose NUMA Topology with Resource Providers for 2026.2 https://review.opendev.org/c/openstack/nova-specs/+/978570
18:29:12 Zhan[m] Hi friends, I have a quick question. Does Nova allow launching/live-migrating VMs to a host with nova-compute disabled? For example, if I want to do a QC before putting the host back to service, I can launch a VM on there with elevated privileges (e.g., using admin credential), make sure everything works, and then finally enable nova-compute.
18:31:30 sean-k-mooney Zhan[m]: no. disbaling a compute node exist to prevent schdulign to the host
18:31:48 sean-k-mooney we enforce this with a frobiden trait via a placment prefilter
18:33:03 sean-k-mooney https://github.com/openstack/nova/blob/master/nova/scheduler/request_filter.py#L243-L255
18:34:06 Zhan[m] Yeah I saw that earlier too. So the only way is to enable it, launch a VM, disable it, make sure everything's correct, and then re-enable it?
18:34:58 sean-k-mooney normlaly i would suggest using somethign else liek a requried trait to isolate the host or teh tenat affinity filter for exmaple
18:35:15 sean-k-mooney i.e. test it by addign teh host to a host aggreate that can only be used by the admin project
18:35:46 sean-k-mooney https://docs.openstack.org/nova/latest/admin/aggregates.html#tenant-isolation-with-placement
18:36:40 sean-k-mooney so restirct it to your admin project, renebaled it, test it adn then eitehr remove it form teh aggreate or disable it again to do futher maintance
18:36:47 Zhan[m] ahh I see, something like a "maintenance" aggregate where only admin can access
18:36:56 sean-k-mooney yep exactly
18:37:00 Zhan[m] I see, thanks!
18:38:16 sean-k-mooney having a third sate enabeld,disabled and maintance woudl perhaps have been a cleaner way to do that but you can emulate that with aggreates
18:40:34 Zhan[m] I think having a third state make sense too, but both approaches solve the same problem ultimately. Wondering if that can be something to discuss and maybe implement, or aggregate is still the recommended way to go?
18:43:08 Zhan[m] It would be good to put this info somewhere, I can imagine others having this question too.
18:47:37 dansmith being able to target disabled hosts seems reasonable to me, without requiring the aggregate thing
18:47:47 dansmith like, if an admin has disabled a host to prevent regular users from scheduling to it,
18:48:06 dansmith but has (of course) the permission to target hosts specifically either with a boot or a migration,
18:48:16 dansmith it seems totally reasonable to ignore the disabled check for that case
18:48:42 dansmith like if I need to disable a failing host, then send a build to it to see if I've fixed it before I let others go there
18:48:58 dansmith or I disable a host to prevent it from filling up so I can emergency migrate instances to it to escape a failing node
18:49:30 Zhan[m] yeah I was actually thinking about replacing the ComputeFilter by a custom filter that will say OK to a disabled host if it's admin and state is up and destination is explicitly specified, until I found that mandatory pre-filter.
18:49:52 dansmith yeah, the pre-filter could do the same
18:53:15 Zhan[m] yeah, I think we can do something in nova that does "if admin (or policy-allowed-role) and if host is specified and if state it up", remove that specific pre-filter?
18:53:47 Zhan[m] imo a third state or this approach both seem fine, just that the prior one may need more changes
18:58:48 sean-k-mooney so it used to be possibel before the pre-filter with --force
18:58:56 sean-k-mooney btu that was because that bypassed everything
18:59:08 sean-k-mooney inclduign the status check provide the compute node existed
18:59:26 Zhan[m] yeah probably not a good idea...
19:02:48 Zhan[m] Any thoughts? Maybe I should do a bug report or a spec?
19:03:44 sean-k-mooney proably a small spec. as its sort of an api change. it is an api change if we had a new state its techinally a policy change adn or cofnig option if we take the other approch
19:03:50 sean-k-mooney so not a bug
19:04:09 Zhan[m] okie dokie, I'll work on it and list all approaches
19:04:19 sean-k-mooney but its not a super invaisve feature given it woudl be highly restrict to admins by default
19:05:52 Zhan[m] definitely, if we add a policy then role will likely be admin by default too. but it's good to have it configurable as folks may create dedicated role for maintenance

Earlier   Later