| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-03-02 | |||
| 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 | |
| 15:01:37 | dansmith | nicolairuckel: how far back are you going with that? | |
| 15:06:40 | opendevreview | Dominik proposed openstack/nova master: NUMA Topology with Resource Providers: Object changes https://review.opendev.org/c/openstack/nova/+/978209 | |
| 15:08:54 | nicolairuckel | just 2025.2 | |
| 15:09:32 | dansmith | ack | |
| 17:59:28 | opendevreview | Merged openstack/python-novaclient master: Update master for stable/2026.1 https://review.opendev.org/c/openstack/python-novaclient/+/978651 | |
| 20:20:53 | melwitt | thanks gibi and stephenfin for fixing the openstack-tox-cover stuff. I had worried the timeout was too low :( sorry for the trouble | |
| 20:28:30 | sean-k-mooney | melwitt:im actully surpised that the coverage collection add so much time to the executionover just adding the time for funtional and unit speratly | |
| 20:29:36 | sean-k-mooney | i mean it kind of make sense in retospect given it has to instroment/trace the actual exercied code paths | |
| 20:29:57 | sean-k-mooney | i just was not expecting it to exceed teh existign timeout | |
| 20:32:42 | melwitt | me too. that's why I mentioned to stephen if he knew some trick to make it faster. it seems disproportionately slow to me but that's just a feeling | |
| 20:34:09 | sean-k-mooney | it may also be one of those thign that sale idfently based on the provider | |
| 20:35:03 | sean-k-mooney | i.e. 4 fast cores on raxflex vs 8 slow cores on rax classic | |
| 20:35:24 | melwitt | hm yeah | |
| 20:36:48 | sean-k-mooney | the last 3 timeout were all on rax clasic on the old xen hardware | |
| 20:36:50 | sean-k-mooney | https://zuul.opendev.org/t/openstack/builds?job_name=openstack-tox-cover&project=openstack/nova | |
| 20:37:33 | melwitt | ahhh heheh. "classic" and "old xen" | |
| 20:38:09 | sean-k-mooney | as were the next 8 | |
| 20:38:32 | sean-k-mooney | so all the one sthat imes out seam to be on the xen vms | |
| 20:40:34 | melwitt | that's good to know. glad there appears to be some explanation | |
| 20:41:35 | sean-k-mooney | tehre are some success there too but my guess is the the xen cloud was flying a bit to close to the sun in terms fo the timeout | |
| 20:41:48 | sean-k-mooney | so if it end up on a busy host it failed | |
| 20:48:01 | melwitt | on wings made of pastrami | |
| 21:22:41 | rm_work[m] | so hey, re: native threads... I see there's a chain of patches that IS required for some stuff to work properly. any chance of backports to like 2025.2 at least? | |
| 21:22:44 | rm_work[m] | https://review.opendev.org/c/openstack/nova/+/956091 | |
| 21:22:53 | rm_work[m] | https://review.opendev.org/c/openstack/nova/+/965466 | |
| 21:22:58 | rm_work[m] | at a minimum it seems these two, not sure if more | |