| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-03-02 | |||
| 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 | |
| 19:07:15 | sean-k-mooney | ya i was debating if the manager role would make sense but i dont think so. but if we have a new policy rule and defautl it to admin then operators can alwasy confirure it to the role they perfer | |
| 19:08:06 | sean-k-mooney | one thing that is not clear to me is if admin shoudl jsut alwasy bypass the check or if this shoudl be opt in either by updating the role or a config option | |
| 19:08:23 | sean-k-mooney | for cross cell migrate we dont even allow admins to do that by default | |
| 19:08:40 | sean-k-mooney | they have ot enable it via custom policy if they want to supprot that in the cloud so this coudl be the same | |
| 19:15:07 | Zhan[m] | I would advocate for including admin in the new policy (default admin too) instead of making it always bypass as it's just very clear & straight forward, people won't need to guess or look at code to know "ok admin can do this". | |
| 19:15:24 | Zhan[m] | I'll put both option in the spec regardless | |
| #openstack-nova - 2026-03-03 | |||
| 08:44:28 | gibi | Uggla: melwitt: I see an increased amount of openstack-tox-cover timeouts https://zuul.opendev.org/t/openstack/builds?job_name=openstack-tox-cover&project=openstack/nova is this potentially related to Iec0a9e38f3641e973894748ab2a14d1bd838e904 ? | |
| 08:47:02 | opendevreview | OpenStack Release Bot proposed openstack/os-vif stable/2026.1: Update .gitreview for stable/2026.1 https://review.opendev.org/c/openstack/os-vif/+/978643 | |
| 08:47:04 | opendevreview | OpenStack Release Bot proposed openstack/os-vif stable/2026.1: Update TOX_CONSTRAINTS_FILE for stable/2026.1 https://review.opendev.org/c/openstack/os-vif/+/978644 | |
| 08:47:06 | opendevreview | OpenStack Release Bot proposed openstack/os-vif master: Update master for stable/2026.1 https://review.opendev.org/c/openstack/os-vif/+/978645 | |
| 08:47:17 | opendevreview | OpenStack Release Bot proposed openstack/osc-placement stable/2026.1: Update .gitreview for stable/2026.1 https://review.opendev.org/c/openstack/osc-placement/+/978646 | |
| 08:47:19 | opendevreview | OpenStack Release Bot proposed openstack/osc-placement stable/2026.1: Update TOX_CONSTRAINTS_FILE for stable/2026.1 https://review.opendev.org/c/openstack/osc-placement/+/978647 | |
| 08:47:21 | opendevreview | OpenStack Release Bot proposed openstack/osc-placement master: Update master for stable/2026.1 https://review.opendev.org/c/openstack/osc-placement/+/978648 | |
| 08:47:32 | opendevreview | OpenStack Release Bot proposed openstack/python-novaclient stable/2026.1: Update .gitreview for stable/2026.1 https://review.opendev.org/c/openstack/python-novaclient/+/978649 | |
| 08:47:34 | opendevreview | OpenStack Release Bot proposed openstack/python-novaclient stable/2026.1: Update TOX_CONSTRAINTS_FILE for stable/2026.1 https://review.opendev.org/c/openstack/python-novaclient/+/978650 | |
| 08:47:37 | opendevreview | OpenStack Release Bot proposed openstack/python-novaclient master: Update master for stable/2026.1 https://review.opendev.org/c/openstack/python-novaclient/+/978651 | |
| 08:49:42 | opendevreview | Balazs Gibizer proposed openstack/nova master: [openstack-tox-cover]Increase timeout https://review.opendev.org/c/openstack/nova/+/978652 | |
| 08:50:02 | gibi | Uggla: melwitt: ^^ bumping the timeout higher | |
| 08:50:22 | gibi | bauzas: stephenfin: sean-k-mooney: ^^ if you are around to land this gate fixing change | |
| 09:20:44 | stephenfin | gibi: ack, done | |
| 09:32:24 | opendevreview | Merged openstack/osc-placement master: Update master for stable/2026.1 https://review.opendev.org/c/openstack/osc-placement/+/978648 | |
| 09:35:29 | opendevreview | Merged openstack/os-vif master: Update master for stable/2026.1 https://review.opendev.org/c/openstack/os-vif/+/978645 | |
| 09:58:16 | opendevreview | Dominik proposed openstack/nova master: NUMA Topology with Resource Providers: Libvirt NUMA Migrate https://review.opendev.org/c/openstack/nova/+/971177 | |
| 10:01:51 | sean-k-mooney | gibi: looks lik it merged | |
| 10:01:57 | sean-k-mooney | well appoved | |
| 10:38:56 | opendevreview | Dominik proposed openstack/nova master: NUMA Topology with Resource Providers: Object changes https://review.opendev.org/c/openstack/nova/+/978209 | |
| 11:21:17 | opendevreview | Stephen Finucane proposed openstack/nova master: Migrate coverage configuration to pyproject https://review.opendev.org/c/openstack/nova/+/978737 | |
| 11:21:17 | opendevreview | Stephen Finucane proposed openstack/nova master: Enable sysmon core https://review.opendev.org/c/openstack/nova/+/978738 | |
| 11:21:48 | stephenfin | gibi: melwitt: That ☝️ needs more investigation, but it might be an option for speeding up our coverage tests | |