| opendevreview | Kamil Sambor proposed openstack/nova master: Replace StaticallyDelayingWrapper with futurist DelayingExecutor https://review.opendev.org/c/openstack/nova/+/997410 | 07:12 |
|---|---|---|
| opendevreview | HyungJoon Kim proposed openstack/nova master: Add regression test for bug #2166652 https://review.opendev.org/c/openstack/nova/+/1004388 | 08:17 |
| gibi | stephenfin: Uggla: do we need to bump the min version of os-vif in nova to 5.2.1? https://github.com/openstack/nova/blob/master/requirements.txt#L54 | 08:48 |
| stephenfin | gibi: Unless we need some particular feature that was added recently, I don't think we have to. The packaging issues was only present in 5.2.0 which won't get dragged in by default | 10:06 |
| stephenfin | 3.1.0 is nearly 4 years old https://pypi.org/project/os-vif/3.1.0/ There's a high possibility it doesn't actually work, but we could likely say the same about a lot of our minimums? | 10:07 |
| stephenfin | So maybe we could bump that, or maybe we should just go and bump to the latest major version (X.0.0) for all our deps? idk | 10:08 |
| opendevreview | HyungJoon Kim proposed openstack/nova master: Sort claimed PCI devices by host PCI address https://review.opendev.org/c/openstack/nova/+/1004411 | 11:10 |
| opendevreview | Merged openstack/os-vif master: Fix typos https://review.opendev.org/c/openstack/os-vif/+/1004326 | 11:33 |
| Uggla | gouthamr, dansmith, melwitt well done for the virtiofs cold migration! 👍 | 12:55 |
| opendevreview | Emma Foley proposed openstack/placement master: [pyproject] Update setuptools config https://review.opendev.org/c/openstack/placement/+/1004418 | 13:17 |
| sean-k-mooney | Uggla: an fyi we may need to fix one packaging issue in placement before we cut rc1 ^ | 13:18 |
| sean-k-mooney | or do an RC2 if we have already done that | 13:18 |
| sean-k-mooney | emma basiclaly is portign the same fix that stephenfin did for nova https://github.com/openstack/nova/commit/3881260b1cb179cd0f8bb2a37282325a5f5fb24a | 13:18 |
| sean-k-mooney | i also fixed this in cybrog watcher as well | 13:22 |
| sean-k-mooney | we shoudl proably check all the pyproject.tomls for this | 13:22 |
| sean-k-mooney | looks like os-vif might be impacted as well https://github.com/openstack/os-vif/blob/master/pyproject.toml#L40-L46 | 13:23 |
| sean-k-mooney | stephenfin: ^ we shoudl fix that too ya? | 13:23 |
| stephenfin | ideally yes | 13:24 |
| stephenfin | Though as I noted in the nova commit message you linked, setuptools currently provides a fallback. It just spews a lot of warnings, and there's a good likelihood the PyPA folks will remove it at some point (they love deleting code more than I do) | 13:25 |
| sean-k-mooney | it was apprently breaking something downstream when we were buidlign placement | 13:25 |
| sean-k-mooney | but for the libs that less of a problem i think | 13:25 |
| sean-k-mooney | so i think we cna fix it in os-vif and the other repos but its less impactful there | 13:26 |
| sean-k-mooney | os-vif is also a bit weired in that we have 3 seperate packages | 13:26 |
| sean-k-mooney | the fined shoudl still work fine | 13:26 |
| sean-k-mooney | but its a littel diffent then placment or nova | 13:26 |
| gibi | stephenfin: OK, so we don't need 5.2.1 os-vif as minimum just need to ignore 5.2.0 which was yanked I guess so it won't get pulled in | 13:27 |
| stephenfin | yeah, there's no reason for 5.2.0 to get pulled in | 13:28 |
| stephenfin | we could yank if we wanted but 🤷 | 13:28 |
| gibi | cool then I think we don't need to risk RC1 to change the minimums now | 13:28 |
| gibi | even though I would like to have better minimums | 13:28 |
| sean-k-mooney | i dont think we added any hard dep on the new version | 13:28 |
| gibi | I just never had the time | 13:29 |
| sean-k-mooney | it fixes some bugs | 13:29 |
| gibi | as of the placement pyproject.toml change, it fails if placement is used as a git submodule | 13:29 |
| sean-k-mooney | but i dont think we are depending on a new fucntionaltiy although neutorn will be enabling a new feature by default | 13:29 |
| gibi | probably to wide matching happens | 13:29 |
| stephenfin | sean-k-mooney: My comment was less about e.g. 5.1.x -> 5.2.x than it was about 3.1.x -> 5.2.x | 13:29 |
| sean-k-mooney | right i dont hink we striclly need to go form 3.1.x to 5.x | 13:30 |
| sean-k-mooney | we shoudl eventully do that | 13:30 |
| sean-k-mooney | as next cycle neuton are removign supprot for disabling a feature that will require the new version in nova | 13:30 |
| sean-k-mooney | today you can configre neuton to work with the older os-vif on the nova side | 13:31 |
| sean-k-mooney | they are makign the new feature the default this cycle | 13:31 |
| sean-k-mooney | so it woudl be good to reaise our min sooner rather then later | 13:31 |
| opendevreview | Stephen Finucane proposed openstack/placement master: tox: Use constraints option https://review.opendev.org/c/openstack/placement/+/996893 | 13:49 |
| opendevreview | Stephen Finucane proposed openstack/placement master: Replace license classifier https://review.opendev.org/c/openstack/placement/+/1004422 | 13:49 |
| opendevreview | Stephen Finucane proposed openstack/placement master: Migrate requirements to pyproject.toml https://review.opendev.org/c/openstack/placement/+/1004423 | 13:49 |
| opendevreview | Stephen Finucane proposed openstack/placement master: [pyproject] Update setuptools config https://review.opendev.org/c/openstack/placement/+/1004418 | 13:50 |
| opendevreview | Stephen Finucane proposed openstack/placement master: Replace license classifier https://review.opendev.org/c/openstack/placement/+/1004422 | 13:50 |
| opendevreview | Stephen Finucane proposed openstack/placement master: tox: Use constraints option https://review.opendev.org/c/openstack/placement/+/996893 | 13:50 |
| opendevreview | Stephen Finucane proposed openstack/placement master: Migrate requirements to pyproject.toml https://review.opendev.org/c/openstack/placement/+/1004423 | 13:50 |
| sean-k-mooney | stephenfin: i assume we will do most of ^ early next cycle | 13:55 |
| stephenfin | the license classifer might be worth doing now, since that's another thing PyPA might pull at a moments notice, but we could backport it later also. The rest can wait | 13:56 |
| sean-k-mooney | that the one i think we shoudl hold | 13:56 |
| sean-k-mooney | well not hold | 13:56 |
| sean-k-mooney | but it was nto suprpoted on older distos | 13:56 |
| sean-k-mooney | right we had to bump to ubuntu 24.04 | 13:56 |
| sean-k-mooney | to have the string form supproted in our package tools | 13:56 |
| sean-k-mooney | i dotn knwo if cents 10 stream ships a new enough setuptools? | 13:56 |
| sean-k-mooney | we just swaped to usign it for pypi in our source to image builds so that hsoudl be fine | 13:57 |
| sean-k-mooney | i just dont knwo about rdo | 13:57 |
| sean-k-mooney | not that that really activly maintianed right now | 13:57 |
| sean-k-mooney | so ya it may jsut be worth checkign the versoin requrieemnt for that before we proced with it | 13:58 |
| sean-k-mooney | that said we have moved a numebr of things to the string already | 13:58 |
| sean-k-mooney | so that ship may have already sailed | 13:58 |
| stephenfin | sean-k-mooney: not quite. The issue was it requires setuptools >= 77.0.0 https://setuptools.pypa.io/en/latest/userguide/license_migration.html | 13:59 |
| stephenfin | and that only supports Python >= 3.9 | 13:59 |
| sean-k-mooney | right but it was capped in rdo, i knwo we had to go fix that btu i dont recall if it was merged | 13:59 |
| sean-k-mooney | i think it was but not entirly sure | 13:59 |
| stephenfin | the change you're thinking of was that we had to move off Ubuntu 20.04 since that ships with Python 3.8 by default | 13:59 |
| stephenfin | move the packaging job off that, more specifically | 14:00 |
| sean-k-mooney | ah it was https://review.rdoproject.org/r/c/deps/python-setuptools/+/58844 | 14:00 |
| sean-k-mooney | stephenfin: for reason rdo was still using 65.5.1 | 14:00 |
| sean-k-mooney | but we fixed that in may so all good | 14:01 |
| stephenfin | cool | 14:01 |
| stephenfin | I mean, if you're talking strictly about packaging rdo could always carry a revert patch too | 14:01 |
| sean-k-mooney | stephenfin: no i was aware of that as well (moving off 20.04) but that was not the only place usign old things to build | 14:01 |
| sean-k-mooney | in general i woudl not advise they ever do that | 14:02 |
| sean-k-mooney | but yes | 14:02 |
| sean-k-mooney | rdo shoudl not carrry patches to the code | 14:02 |
| stephenfin | The distro setuptools version no longer matters for installs with pip since builds are isolated by default, so it would only be packaging (or the aforementioned "my Python is too old") scenarios that would break | 14:02 |
| stephenfin | agree, but the escape hatch is there | 14:03 |
| stephenfin | speaking of escape hatches, looks like setuptools' docs aren't happy https://setuptools.pypa.io/en/latest/userguide/license_migration.html | 14:03 |
| sean-k-mooney | yep, although i belive we have to disabel build isolation in some case for downsteam reasons | 14:03 |
| stephenfin | I could fix it but they ignore my issues so 🤷 | 14:03 |
| sean-k-mooney | specifcly to use a fips complient python-cyrotography | 14:04 |
| stephenfin | not bitter... | 14:04 |
| stephenfin | sean-k-mooney: you need a fips-complint cryptopgraphy during build?? | 14:04 |
| stephenfin | *compliant | 14:04 |
| sean-k-mooney | yes and in the final artifact | 14:05 |
| sean-k-mooney | anyway htat out of scope fo upstream | 14:05 |
| sean-k-mooney | but downstream python3-cyrptograph must come form the rpms for complance reasons as it need to be built with a specific fips certifed version fo openssl ectra | 14:06 |
| opendevreview | ribaudr proposed openstack/nova master: This adds an alias for Hibiscus https://review.opendev.org/c/openstack/nova/+/1004424 | 14:09 |
| opendevreview | ribaudr proposed openstack/nova master: Add service version for Hibiscus https://review.opendev.org/c/openstack/nova/+/1004430 | 14:24 |
| opendevreview | ribaudr proposed openstack/nova-specs master: Move Hibiscus implemented specs https://review.opendev.org/c/openstack/nova-specs/+/1004442 | 15:29 |
| Uggla | Reminder: upstream meeting in ~20mn | 15:42 |
| gibi | Uggla: I added a topic to the open discussion agenda | 15:45 |
| Uggla | gibi, ok! | 15:46 |
| * bauzas was just one click away from upgrading his DSM server until he remembered that his IRC bouncer is on that server :) | 16:00 | |
| Uggla | #startmeeting nova | 16:00 |
| opendevmeet | Meeting started Mon Sep 7 16:00:47 2026 UTC and is due to finish in 60 minutes. The chair is Uggla. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
| opendevmeet | The meeting name has been set to 'nova' | 16:00 |
| Uggla | Hello everyone | 16:00 |
| fwiesel | o/ | 16:00 |
| bauzas | o/ | 16:00 |
| sambork | o/ | 16:01 |
| tkajinam | o/ | 16:02 |
| Uggla | Let's start | 16:03 |
| Uggla | #topic Bugs (stuck/critical) | 16:03 |
| Uggla | #info No Critical bug | 16:03 |
| Uggla | #topic Gate status | 16:04 |
| Uggla | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | 16:04 |
| Uggla | #link https://etherpad.opendev.org/p/nova-ci-failures-minimal | 16:04 |
| Uggla | #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&branch=stable%2F*&branch=master&pipeline=periodic-weekly&skip=0 Nova&Placement periodic jobs status | 16:04 |
| Uggla | #info Please look at the gate failures and file a bug report with the gate-failure tag. | 16:04 |
| Uggla | #info Please try to provide a meaningful comment when you recheck | 16:04 |
| gibi | o/ | 16:04 |
| Uggla | Anything new about the gate? | 16:05 |
| gibi | I had to put the functional test stabiliziton on hold for now due to internal priorities. But we still have some unstability in the functional threading job | 16:05 |
| gibi | and I have in flight patches to work on | 16:05 |
| gibi | but it need to wait a bit | 16:05 |
| Uggla | Yep I know about one on my side. | 16:06 |
| gibi | feel free to ping me if you see a functional instability and I will help judging it if it needs a new tracker or if we already have one | 16:06 |
| Uggla | are we good for that topic ? | 16:07 |
| Uggla | #topic Release Planning | 16:07 |
| Uggla | #link https://releases.openstack.org/hibiscus/schedule.html | 16:07 |
| Uggla | #info Nova deadlines are set in the above schedule | 16:08 |
| Uggla | #info RC1 target week. | 16:08 |
| * Uggla working on pre RC1 patches. (in progress). | 16:08 | |
| Uggla | I should propose the highlight patch shortly. | 16:09 |
| Uggla | #topic Review priorities | 16:09 |
| Uggla | #link New file for Hibiscus https://etherpad.opendev.org/p/nova-2026.2-status | 16:09 |
| Uggla | #info Starting: https://etherpad.opendev.org/p/nova-2026.2-status#L16 interesting bugs to review. | 16:09 |
| bauzas | ack | 16:09 |
| bauzas | don't hesitate to ping me, I have a microtime I can use for upstream reviews :) | 16:10 |
| Uggla | bauzas sure. Thanks! | 16:10 |
| Uggla | #topic Stable Branches | 16:10 |
| bauzas | (more time than the time it takes for the light in between Moon and Earth, but less than a Earth round) | 16:10 |
| Uggla | I know elodilles is on a business trip so I don't know if he can make it. | 16:11 |
| Uggla | seems not, so lets move on or defer it later. | 16:12 |
| gibi | I think it is pretty late for Elod at the moment | 16:12 |
| Uggla | yep probably. | 16:12 |
| Uggla | #topic vmwareapi 3rd-party CI efforts Highlights | 16:12 |
| fwiesel | Hi, no updates from my side. | 16:13 |
| Uggla | fwiesel something you'd like to share? | 16:13 |
| Uggla | ok thanks. Welcome back! | 16:13 |
| fwiesel | Thanks! | 16:13 |
| Uggla | #topic Kamil's news about eventlet removal | 16:13 |
| Uggla | sambork, gibi something to report on that front ? | 16:13 |
| sambork | Not much since last week, key fix: restored eager thread executor creation in service managers rather than lazily in thread_pool_factory.py (#1001572) .Meanwhile, patch 1001369 (native threading test fix) waiting for update. Separately, patch 997410 (review) was updated to use futurist.DelayingExecutor, though it will merge in next release | 16:14 |
| sambork | eom | 16:14 |
| gibi | nothing to add form my side. I will continue stabilizing the functional tests when I get some time | 16:15 |
| Uggla | sambork, gibi I'll notify you about the HL patch as soon as ready, so we could iterate to report the meaningful changes. | 16:15 |
| Uggla | skipping sdk for neutron topic as Layos is not available. | 16:16 |
| Uggla | #topic Confidential computing, status of SNP and TDX features | 16:16 |
| Uggla | I guess nothing new here. | 16:16 |
| tkajinam | yeah | 16:16 |
| gibi | yeah | 16:16 |
| antia | https://review.opendev.org/c/openstack/whitebox-tempest-plugin/+/1003958 | 16:17 |
| gibi | oooh | 16:17 |
| tkajinam | oh nice | 16:17 |
| gibi | niiice | 16:17 |
| antia | I took the chance to submit those | 16:17 |
| gibi | antia: thanks I will check it | 16:17 |
| Uggla | cool antia! | 16:17 |
| antia | gibi: Thanks! | 16:17 |
| antia | nothing else from me | 16:18 |
| Uggla | would you guys want to maintain this topic. I think we can remove it now? | 16:18 |
| gibi | Uggla: I'm OK to drop it | 16:19 |
| gibi | thanks everyone :) | 16:19 |
| Uggla | or course we can speak about it if we need in open discussion | 16:19 |
| tkajinam | yeah I think we can remove it from the regular agenda. | 16:20 |
| Uggla | and yes thanks for this great collaboration around those topics. | 16:20 |
| Uggla | #topic Bug scrubbing | 16:20 |
| Uggla | #info down to 67 (-1). | 16:20 |
| Uggla | #link https://etherpad.opendev.org/p/nova-bug-triage-roster | 16:21 |
| Uggla | #link https://truc.uggla.fr/ to follow the trend. | 16:21 |
| Uggla | #info Next meeting (this week): [public] Upstream bug triage. Wednesday, Septembre 09th · 15:30 – 16:00 UTC. Video call link: meet.google.com/zjr-rxus-hzj | 16:21 |
| Uggla | #topic Open discussion | 16:21 |
| Uggla | on topic from gibi | 16:22 |
| Uggla | (gibi): I need technical guidance what to do with https://bugs.launchpad.net/nova/+bug/2166474 (Uggla: I will describe the case on the meeting) | 16:22 |
| * Uggla giving the mic to gibi | 16:23 | |
| gibi | o/ | 16:24 |
| gibi | so we have that bug, it describe a nasty race where nova allows two evacuation action to overlap on the same VM at the same time | 16:24 |
| gibi | then today I realized that we started allowing that couple of years ago | 16:24 |
| gibi | by allowing evacuation from a non empty task_state | 16:24 |
| gibi | to support things like | 16:25 |
| gibi | 1. compute with a VM dies | 16:25 |
| gibi | 2. owner try to restart the VM, VM goes to powering_off task_state that never progresses | 16:25 |
| gibi | 3. operator realizes that the compute is dead an wants to evacuate the VM | 16:25 |
| gibi | to support this nova allows triggering evacuation with task_state not empty | 16:26 |
| gibi | but task_state is our lock to avoid two operation to overlap on the same VM | 16:26 |
| gibi | obviously I can develop a patch that allow evacuation to start only from non rebuilding* task_state | 16:27 |
| gibi | but that only solves the currently proven overlap | 16:27 |
| gibi | I'm a bit hesitant about all the other task states what should be allowed and what should not | 16:28 |
| gibi | so ideas folks? | 16:28 |
| gibi | (here or offline in the bug) | 16:28 |
| bauzas | I see | 16:28 |
| bauzas | took a bit of time to load the context | 16:28 |
| bauzas | we relied on task_state for knowing whether we were having an user instance action | 16:28 |
| bauzas | but given it was an issue if we want to evacuate, we removed the conditional | 16:29 |
| gibi | yeah | 16:29 |
| bauzas | but now we dunno whether a current task state is because of an user action or because an evacuation is starting, right? | 16:29 |
| gibi | right, basically we don't know if a non empty task_state at the start of evacuation means an action that cannot progress because it is against the dead compute and therefore allowed to evacuate, or it measn an action that is progressing already on another compute for this VM like a previous evac | 16:30 |
| bauzas | hmmm OK | 16:31 |
| gibi | but also a previous evac can be against the dead compute | 16:31 |
| bauzas | (thinking) | 16:31 |
| gibi | so in theory you might want to re-try evacuation as the previous evac is not progressing as that compute died during evac | 16:31 |
| bauzas | I guess we can't look at the VM state thn ? | 16:31 |
| gibi | not fully mapped the states, but I think you want to be able to evac from ACTIVE, STOPPED, ERROR | 16:32 |
| bauzas | and we don't have a Migration object when evacuating ? | 16:32 |
| bauzas | because we could look at it | 16:32 |
| gibi | we have but we can have multiple unfinished migration object with type evac | 16:32 |
| gibi | having a migration object does not mean the action of that migration can progress | 16:33 |
| bauzas | hmmmm | 16:33 |
| gibi | maybe the dest or the source of the migration is dead and you want to evac :) | 16:33 |
| gibi | so a perfect solution is impossible I think | 16:33 |
| gibi | we need to compromise some requirements | 16:33 |
| tkajinam | the most safe approach might be add new api microversion to require task_state=None and require operators to do reset-state | 16:34 |
| tkajinam | though I know that's not something operators may like | 16:34 |
| gibi | I will never ask an operator in our do to do a reset-state | 16:34 |
| gibi | that is like asking for a bigger problem because you had a small one :) | 16:34 |
| gibi | s/in our do/ in our doc/ | 16:35 |
| tkajinam | hmm ok. I agree | 16:35 |
| gibi | I mean I spent so many time in customer cases where the deployer used reset-state and created a big mess | 16:36 |
| gibi | maybe, a smarter reset-state... | 16:36 |
| tkajinam | I know :-) | 16:36 |
| gibi | but that is probably the same problem of deciding what action can be reset safely | 16:36 |
| gibi | the same task_state can be ignored in evac precondition as well | 16:36 |
| bauzas | are we already checking in the API evacuation API whether an evacuation is already run ? | 16:37 |
| gibi | we checked in the past by looking at the task_state, but we removed that check effectively when we started allowing to evacuate from task_state=powering_off to support the above use cae | 16:38 |
| gibi | case | 16:38 |
| bauzas | https://github.com/openstack/nova/blob/master/nova/compute/api.py#L5747 | 16:39 |
| gibi | btw task_state=power_off can happen *during* an evac, as we started evacuating to STOPed state in microvesrion 2.95 | 16:40 |
| bauzas | here, we ask for a task state to be None, right? | 16:40 |
| gibi | bauzas: that task_state=None means do not check task_state, the code that expects an empty task_state is expected_task_state=(None,) | 16:40 |
| gibi | or [None] | 16:41 |
| bauzas | sorry, yeah | 16:41 |
| bauzas | so we could say that we expect no task state | 16:41 |
| gibi | no we cannot as that breaks the evac from task_state=powering_off case | 16:41 |
| bauzas | but if we have an exception, we could look at the task state | 16:41 |
| gibi | we support since 2022 | 16:41 |
| bauzas | I mean, if we get a task state here, we can look whether this is due to an already existing rebuild task | 16:42 |
| gibi | the problem is basically what task_state is allowed and what does not | 16:42 |
| bauzas | if so, we can say "mmmh, nope" | 16:42 |
| gibi | I don't have a list of allowable task_states | 16:43 |
| gibi | I don't even have a list of definietly rejectable task_states | 16:43 |
| gibi | as rebuild* task_state could mean an ongoing evac, or a failed evac that you want to retry | 16:43 |
| gibi | where failed, is failed do the dest compute is dead | 16:43 |
| gibi | s/do the/ do to/ | 16:44 |
| gibi | s/do the/ due to/ | 16:44 |
| bauzas | oh right the problem is not only when concurrent evacuation requests, this is also about ensuring we can ask for evac again if it fails | 16:44 |
| bauzas | but if the evac failed, then the instance is not in ACTIVE vm state, right ? | 16:45 |
| bauzas | I have to look at the code | 16:45 |
| bauzas | I don't think we move the instance back to ACTIVE if we fail on evac | 16:46 |
| bauzas | (compared to migrations for example) | 16:46 |
| gibi | I guess I can propose PTG topic :) | 16:46 |
| gibi | or write a book about distributes systems :) | 16:46 |
| tkajinam | if evacuation "fails" normally it may be easy though if compute node dies in the middle then evacuation may get stuck | 16:46 |
| tkajinam | can we check state of the dest compute node to determine whether the current evac can progress ? | 16:47 |
| opendevreview | Ashish Gupta proposed openstack/nova master: Fix init_host crash migration test under native threading https://review.opendev.org/c/openstack/nova/+/1001369 | 16:47 |
| gibi | bauzas: evac is possible from ERROR state :) | 16:48 |
| bauzas | doh | 16:48 |
| gibi | tkajinam: the dest compute is not well defined unfortunately | 16:48 |
| bauzas | gibi: if you write a book about distributed systems, you wouldn't be the first :) | 16:48 |
| gibi | there is instance.host that evacuate sets pretty late. There is the migration object dest host but we can have multiple unfinished evacuation migration object with different dests | 16:49 |
| bauzas | I guess this sounds a PTG discussion indeed | 16:49 |
| tkajinam | yeah | 16:49 |
| gibi | bauzas: mine will solve it! | 16:49 |
| gibi | :) | 16:49 |
| bauzas | hah then I can review | 16:49 |
| bauzas | provided you're not proposing a state machine :) | 16:50 |
| gibi | you will get a dedicate pre-release copy of it for sure | 16:50 |
| gibi | "a" state machine that is short sighted :) | 16:50 |
| bauzas | if someone says "etcd will solve that", I swear I will find you | 16:50 |
| gibi | OK I think I will propose a ptg topic | 16:50 |
| Uggla | etcd will solve that :) | 16:51 |
| bauzas | I'll find you | 16:51 |
| bauzas | and I know your home | 16:51 |
| gibi | there are "better" (mean newer) trials than etcd :) | 16:51 |
| Uggla | ;) | 16:51 |
| gibi | anyhow I think I'm done here. mic drop | 16:51 |
| bauzas | gibi: so, are you asking for reviews about your WIP or do we punt that to PTG? | 16:51 |
| gibi | bauzas: feel free to read the commit message of my WIP and my last comment on the bug | 16:52 |
| bauzas | it will require a substantial amount of context loading, but that sounds a nasty bug tho | 16:52 |
| gibi | but we won't have solution on RC1 week | 16:52 |
| bauzas | gibi: OK'll try | 16:52 |
| Uggla | To my mind that sounds complex enough to discuss to the PTG. | 16:52 |
| gibi | so we can continue after H release | 16:52 |
| gibi | probably on the PTG (depending of downstream push) | 16:52 |
| Uggla | ok | 16:53 |
| bauzas | my concern is that a PTG discussion will probably require some prerequisite effort for context loading | 16:53 |
| gibi | I will create more context if this will end up being a PTG topic | 16:53 |
| bauzas | cool | 16:53 |
| gibi | I cannot help loading it though | 16:53 |
| Uggla | anything else to discuss in the last 5mn, if not I think we are done. | 16:54 |
| gibi | I don't yet have a remote exploit in your head | 16:54 |
| bauzas | well, I think I know how we manage our VM and task states, but I'm more concerned by the quirks we have in code (all the nasty assumptions we have as code conditionals) | 16:54 |
| gibi | (sssh do not tell them) | 16:54 |
| bauzas | I could write a book about all nova API preconditions | 16:55 |
| bauzas | (that one would probably be new compared to some random book about distributed systems :D ) | 16:55 |
| Uggla | ok so closing now. | 16:56 |
| Uggla | Thanks for joining this meeting. Have a nice day/evening. | 16:56 |
| Uggla | #endmeeting | 16:57 |
| opendevmeet | Meeting ended Mon Sep 7 16:57:02 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:57 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2026/nova.2026-09-07-16.00.html | 16:57 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2026/nova.2026-09-07-16.00.txt | 16:57 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2026/nova.2026-09-07-16.00.log.html | 16:57 |
| bauzas | interesting talks, thanks | 16:57 |
| gibi | thanks folks | 16:58 |
| gibi | I'm dropping for today | 16:58 |
| tkajinam | thanks | 16:59 |
| Uggla | gibi, bauzas, gmaan, sambork, dansmith, melwitt, gouthamr, sean-k-mooney https://review.opendev.org/c/openstack/releases/+/1004465 if you'd like to update/review the highlight | 17:10 |
| sean-k-mooney | we could note the startup time improvment but that about it form me i think the prelude looks reasonabel as is | 17:16 |
| *** mhen_ is now known as mhen | 18:07 | |
| *** nicolairuckel_ is now known as nicolairuckel | 18:09 | |
| opendevreview | Merged openstack/placement master: [pyproject] Update setuptools config https://review.opendev.org/c/openstack/placement/+/1004418 | 19:21 |
| opendevreview | Merged openstack/nova master: Parallelize per-node resource updates https://review.opendev.org/c/openstack/nova/+/980679 | 21:05 |
| gouthamr | Uggla: Ty, looks great - except the name of the release :) | 23:59 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!