| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-03-02 | |||
| 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 | |
| 11:23:24 | stephenfin | Ideally we'd run on py314 since we get the faster profiler *and* branch coverage, but we're a bit awat from that | |
| 11:23:56 | sean-k-mooney | so 3.14 is currently failing on some oslo.service issues with how we init the backend | |
| 11:24:09 | sean-k-mooney | we shoudl fix that as soon as we can to get that job passign then sure | |
| 11:25:21 | sean-k-mooney | stephenfin: i replied in the review but swaping to sysmon si not a good trade off if it woudl prevent use testing with threaded mode | |
| 11:25:53 | sean-k-mooney | early next cycle that will be the defualt for nova-compute as well and its already the defautl for the api, schduler and conductor i bleive | |
| 11:26:52 | sean-k-mooney | so anything that would make it harder to have the tox target test how we deploy in production (in threaded mode) next cycle woudl be a regression even if its faster | |
| 11:28:40 | sean-k-mooney | the first commit im +2 on | |
| 11:29:39 | sean-k-mooney | the second might want to wait until we can run it on py3.14 as you said. its now aviabel in the gate but we need to get 3.14 in general passing first | |
| 11:37:50 | opendevreview | Dominik proposed openstack/nova master: NUMA Topology with Resource Providers: Scheduler changes https://review.opendev.org/c/openstack/nova/+/971176 | |
| 12:02:22 | opendevreview | Dominik proposed openstack/nova master: NUMA Topology with Resource Providers: Libvirt NUMA Migrate https://review.opendev.org/c/openstack/nova/+/971177 | |
| 12:05:12 | opendevreview | Merged openstack/nova master: Rename deadline parameter to more accurate timeout https://review.opendev.org/c/openstack/nova/+/957411 | |
| 12:12:23 | opendevreview | Dominik proposed openstack/nova master: Regression test for Placement allocations remaining during failed schedule https://review.opendev.org/c/openstack/nova/+/969251 | |
| 12:14:48 | opendevreview | Merged openstack/os-vif stable/2026.1: Update .gitreview for stable/2026.1 https://review.opendev.org/c/openstack/os-vif/+/978643 | |
| 12:15:19 | opendevreview | Merged openstack/osc-placement stable/2026.1: Update .gitreview for stable/2026.1 https://review.opendev.org/c/openstack/osc-placement/+/978646 | |
| 12:15:31 | opendevreview | Merged openstack/os-vif stable/2026.1: Update TOX_CONSTRAINTS_FILE for stable/2026.1 https://review.opendev.org/c/openstack/os-vif/+/978644 | |
| 12:19:27 | opendevreview | Merged openstack/osc-placement stable/2026.1: Update TOX_CONSTRAINTS_FILE for stable/2026.1 https://review.opendev.org/c/openstack/osc-placement/+/978647 | |
| 14:08:47 | opendevreview | Doug Goldstein proposed openstack/nova master: return error about external network to the user on build failure https://review.opendev.org/c/openstack/nova/+/972601 | |
| 14:36:30 | nicolairuckel | gibi, elodilles: You said I should use `git cherry-pick -x` for backporting. I'm getting merge conflicts though and according to the man page of cherry-pick that `-x` only works if there are no conflicts. Is this a problem or can I just fix my merge conflicts and create a new merge request? | |
| 14:41:45 | dansmith | nicolairuckel: -x has nothing to do with conflicts.. the man page is describing a style not a rule (incorrectly, IMHO) | |
| 14:42:14 | dansmith | nicolairuckel: you must use -x for openstack regardless of conflicts.. and you're going to have conflicts. you just need to resolve them manually | |
| 14:42:59 | nicolairuckel | okay, thanks | |
| 14:43:24 | elodilles | nicolairuckel: as dansmith says :) also when resolving conflicts please keep "Conflicts" lines in the commit message to help reviewers (e.g. https://review.opendev.org/c/openstack/nova/+/686292 ) | |
| 14:45:06 | nicolairuckel | got it | |
| 14:58:04 | opendevreview | Nicolai Ruckel proposed openstack/nova stable/2025.2: Preserve UEFI NVRAM variable store https://review.opendev.org/c/openstack/nova/+/978766 | |