| *** elodilles_pto is now known as elodilles | 07:55 | |
| Uggla | Reminder: Today is spec review day. | 09:55 |
|---|---|---|
| Uggla | Happy reviews. | 09:56 |
| priteau | Hello Nova folks. I think I have hit this bug last week: https://bugs.launchpad.net/nova/+bug/2084238. I shelved an instance with a GPU device in PCI passthrough mode, and now it won't unshelve. Any thoughts on the issue? | 12:41 |
| opendevreview | Merged openstack/nova-specs master: Re-propose "libvirt: AMD SEV-ES support" for 2025.2 https://review.opendev.org/c/openstack/nova-specs/+/950429 | 13:29 |
| dansmith | priteau: is it pre-existing instances (instanced created before the upgrade) that are stuck? | 13:40 |
| priteau | Yes, this instance is a few years old. | 13:46 |
| dansmith | priteau: okay does that mean new instances aren't affected? | 13:50 |
| dansmith | I'd have to look at what's going on here, but sounds like maybe a failed migration | 13:50 |
| dansmith | have you run all your online data migrations post-upgrade? | 13:50 |
| priteau | We've done all upgrades in the same way, with Kolla, which should have run all database migrations | 14:01 |
| dansmith | priteau: not all data migrations are critical, and some are opportunistic | 14:05 |
| dansmith | priteau: so it would be best just to confirm, but if you prefer to just assume... | 14:05 |
| WJeffs49 | Hey all, Working on some upgrade testing 2023.1 -> 2024.1, mostly all happy, but having some odd api issues after. mostly all working, I can query most stuff fine, but some stuff fails 90% of the time. Only error I can fine is in nova_api logs: Timeout when reading response headers from daemon process 'nova-api': | 14:06 |
| WJeffs49 | /var/lib/kolla/venv/bin/nova-api-wsgi. Anyone got any ideas? | 14:06 |
| opendevreview | Merged openstack/os-vif stable/2025.1: OVS Trunk: Add bridge_name to external_ids https://review.opendev.org/c/openstack/os-vif/+/952567 | 14:22 |
| ralonsoh | hello folks, what do I need to enable tags plugin/extension in Nova? | 14:28 |
| ralonsoh | openstack.exceptions.NotFoundException: NotFoundException: 404: Client Error for url: http://192.168.10.100/compute/v2.1/servers/91c188f8-fcc7-4f10-b819-10b740828feb/tags/t1, The resource could not be found. | 14:28 |
| ralonsoh | I have this issue when trying to set a tag for a server | 14:28 |
| ralonsoh | $ openstack server set --tag t1 s21 | 14:28 |
| dansmith | ralonsoh: we don't have plugins or extensions | 14:31 |
| ralonsoh | dansmith, yeah, I didn't know how to call it | 14:31 |
| dansmith | ralonsoh: might require choosing the right microversion though | 14:31 |
| dansmith | I thought osc uses $latest now though | 14:31 |
| ralonsoh | but usually the CLI returns what is the version needed | 14:32 |
| dansmith | does it? | 14:32 |
| dansmith | https://docs.openstack.org/api-ref/compute/#server-tags-servers-tags | 14:32 |
| ralonsoh | for example, with live-mighration --host | 14:32 |
| dansmith | 2.26 | 14:32 |
| ralonsoh | thanks! | 14:33 |
| dansmith | did that work? | 14:33 |
| ralonsoh | ahh yes, now | 14:35 |
| ralonsoh | thanks! | 14:35 |
| dansmith | cool | 14:36 |
| Uggla | Nova meeting in ~1h | 15:03 |
| opendevreview | Lajos Katona proposed openstack/os-vif stable/2024.2: OVS Trunk: Add bridge_name to external_ids https://review.opendev.org/c/openstack/os-vif/+/952778 | 15:49 |
| Uggla | #startmeeting nova | 16:02 |
| opendevmeet | Meeting started Tue Jun 17 16:02:52 2025 UTC and is due to finish in 60 minutes. The chair is Uggla. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:02 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:02 |
| opendevmeet | The meeting name has been set to 'nova' | 16:02 |
| Uggla | Hello everyone | 16:03 |
| elodilles | o/ | 16:03 |
| Uggla | awaiting people to join. | 16:03 |
| bauzas | o/ | 16:04 |
| fwiesel | o/ | 16:04 |
| gmaan | o/ | 16:05 |
| Uggla | Let's start slowly as I know some folks are part of another meeting. | 16:05 |
| Uggla | #topic Bugs (stuck/critical) | 16:06 |
| Uggla | #info No Critical bug | 16:06 |
| Uggla | #topic Gate status | 16:06 |
| Uggla | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | 16:06 |
| Uggla | #link https://etherpad.opendev.org/p/nova-ci-failures-minimal | 16:06 |
| 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:07 |
| Uggla | #info Please look at the gate failures and file a bug report with the gate-failure tag. | 16:07 |
| Uggla | #info Please try to provide meaningful comment when you recheck | 16:07 |
| * gibi is on a different meeting in parallel | 16:07 | |
| Uggla | gibi, I know. | 16:08 |
| Uggla | ;) | 16:08 |
| gibi | I know you know j) | 16:08 |
| Uggla | #topic tempest-with-latest-microversion job status | 16:09 |
| Uggla | #link https://zuul.opendev.org/t/openstack/builds?job_name=tempest-with-latest-microversion&skip=0 | 16:09 |
| Uggla | gmaan, something you want to tell about it ? | 16:09 |
| gmaan | no new updates. did not get chance to progress on this. | 16:09 |
| gmaan | #link https://review.opendev.org/q/topic:%22latest-microversion-testing%22 | 16:10 |
| gmaan | this is latest changes/progress | 16:10 |
| Uggla | no worries, that's a marathon not a sprint. | 16:10 |
| Uggla | #topic Release Planning | 16:11 |
| Uggla | #link https://releases.openstack.org/flamingo/schedule.html | 16:11 |
| Uggla | #info Nova deadlines are set in the above schedule | 16:11 |
| Uggla | #info Nova Spec review day is today. | 16:12 |
| Uggla | tbh, I have not reviewed specs today. Due to a couple of escalations. So I will do that tomorrow. | 16:13 |
| bauzas | I did a few specs reviews \o/ | 16:14 |
| bauzas | I'll continue tomorrow | 16:14 |
| Uggla | bauzas, \o/ | 16:15 |
| bauzas | I mean, I'm happy to see Gerrit eventually this month :) | 16:17 |
| bauzas | Gerrit, I missed you | 16:17 |
| Uggla | there is still time for people in the us. (for reviews) | 16:17 |
| * gibi was also busy elsewhere but try to review some specs hopefully tomorrow | 16:18 | |
| Uggla | gibi ++ | 16:18 |
| Uggla | #topic Review priorities | 16:19 |
| gmaan | i will check a few today, | 16:19 |
| Uggla | #link https://etherpad.opendev.org/p/nova-2025.2-status | 16:19 |
| Uggla | gmaan, thx | 16:19 |
| Uggla | I'll try to update the doc by next week, to have a better view of what has been reviewed and what's left. | 16:20 |
| Uggla | #topic OpenAPI | 16:21 |
| Uggla | #link: https://review.opendev.org/q/topic:%22openapi%22+(project:openstack/nova+OR+project:openstack/placement)+-status:merged+-status:abandoned | 16:21 |
| Uggla | #info 20 increase +2 due to FUP. | 16:21 |
| Uggla | but we did progress on this one. | 16:21 |
| Uggla | #topic Stable Branches | 16:22 |
| Uggla | elodilles, I give you the mic | 16:22 |
| elodilles | thanks Uggla , | 16:22 |
| elodilles | as far as i know: | 16:22 |
| elodilles | #info stable branches (stable/2025.1 and stable/2024.*) seem to be in OK state | 16:22 |
| elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | 16:22 |
| elodilles | please add issues here ^^^ if you find one | 16:23 |
| elodilles | that's all from me about stable | 16:23 |
| elodilles | Uggla: back to you | 16:23 |
| Uggla | thx elodilles | 16:23 |
| elodilles | np | 16:23 |
| Uggla | #topic vmwareapi 3rd-party CI efforts Highlights | 16:23 |
| fwiesel | Hi, no updates there. | 16:23 |
| Uggla | fwiesel, ok thx. | 16:24 |
| Uggla | #topic Gibi's news about eventlet removal. | 16:24 |
| Uggla | #link Blog: https://gibizer.github.io/categories/eventlet/ | 16:24 |
| Uggla | #link nova-scheduler series is ready for core review, starting at https://review.opendev.org/c/openstack/nova/+/947966 | 16:24 |
| Uggla | gibi do you want to share something ? | 16:24 |
| bauzas | I guess he provided a revision so the next need will be to review it | 16:27 |
| bauzas | (which is something I'll do) | 16:27 |
| Uggla | I know he added some stuff on top of the serie to improve logging. | 16:28 |
| gibi | sorry | 16:28 |
| gibi | to many discussins in parallel | 16:28 |
| gibi | so | 16:28 |
| gibi | thanks for the review I fixed most of the comments we gathered on the last weeks sycn | 16:29 |
| opendevreview | Abhishek Kekane proposed openstack/nova master: Revert^2 "Support glance's new location API" https://review.opendev.org/c/openstack/nova/+/950623 | 16:29 |
| gibi | there is one comment form sean-k-mooney about the spanwissynchronous fixture I have to work on | 16:29 |
| gibi | it actually pointed to an independent nova bug | 16:29 |
| gibi | I linked to the channel last evening | 16:29 |
| gibi | other than that the series is reviewable | 16:30 |
| gibi | and yes there are some logging improvement on top of the series based on the last week's sync | 16:30 |
| gibi | and at some point I will add one proposal to the futurist lib as well for executor utilization | 16:30 |
| gibi | other than this I dropped a "bomb" on the mailing list | 16:31 |
| gibi | about the eventlet removal timelien | 16:31 |
| Uggla | using spawn instead of fork ? | 16:31 |
| gibi | as 2026.2 is pretty streched for us based on our progress | 16:31 |
| gibi | Uggla: nope just utilization logging | 16:31 |
| Uggla | ok | 16:32 |
| gibi | I have to go back to that ML thread as there are replys | 16:32 |
| gibi | I expect TC will be involved | 16:32 |
| gibi | that is all | 16:32 |
| bauzas | We'll discuss it today at the TC meeting | 16:33 |
| Uggla | maybe we could discuss news about that in the weekly meeting about eventlet. | 16:33 |
| gmaan | I think we will be discussing it in today meeting | 16:33 |
| gmaan | yeah | 16:33 |
| sean-k-mooney | gibi: are you refering to the spawn_on interaction or a diffent nova issue | 16:33 |
| bauzas | In the open discussion | 16:33 |
| bauzas | (I added the topic? | 16:33 |
| bauzas | ) | 16:33 |
| sean-k-mooney | gibi: we dont need to go into detail just wondering if it was somethign else | 16:33 |
| gibi | sean-k-mooney: yepp the spawn_on pointed to the bug I linked yesterady about the decorator on the build_and_run_instance | 16:34 |
| sean-k-mooney | oh that | 16:34 |
| sean-k-mooney | ok thanks for the context | 16:34 |
| gibi | nhp | 16:34 |
| gibi | np | 16:34 |
| gibi | btw this is the eventlet removal ML thread https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/BIC7BTAN72X6AA4BE6VVNSP7FYFOC362/ | 16:34 |
| gibi | just for the record | 16:34 |
| Uggla | +1 | 16:34 |
| gibi | that is all from me | 16:35 |
| Uggla | thx gibi, moving on. | 16:35 |
| Uggla | #topic Bridging the Gap: metrics and survey analyses | 16:35 |
| fungi | i'll try to be quick, but there's a lot we dug into... for some background on openstack-wide metrics analysis see ildikov's most recent ml post yesterday: | 16:35 |
| fungi | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/NTBNI7YIDCWBR6BTPEKVZIODWTVUIOXO/ BtG metrics analysis | 16:35 |
| fungi | also could be worthwhile to revisit her previous post in that thread going over the contributor and survey results (and anyone who hasn't filled those out for epoxy, please see if you can find a few minutes to do that!) | 16:35 |
| fungi | as a follow-up activity, we've started doing some team-specific analyses, focusing on teams that had multiple contributor and maintainer survey responses | 16:36 |
| fungi | the contributor survey had 2 responses for nova and both respondents had contributed for at least 2 years and were contributors to at least two other open source projects | 16:36 |
| fungi | most feedback was relatively neutral (averaging 3-3.5 out of 5) with the lowest score being a 2 on "Changes you propose are reviewed in a timely manner" | 16:36 |
| fungi | "You receive actionable feedback from other reviewers" had the widest skew, with a 2 and a 5 from the respondents | 16:36 |
| fungi | top challenges reported were trouble with review attention, unhelpful comments and reviewers asking to expand the scope of the change | 16:36 |
| fungi | additional feedback noted that the team seemed to have more work backlog than people available to manage it, and that change prioritization seemed to be a struggle | 16:37 |
| fungi | the maintainer survey also had 2 responses with overall higher scores than the cntributor survey (averaging 3-4.5) | 16:37 |
| fungi | contributing challenges reported were similar to those from the other survey, but specifically called out slow review times leading to changes with one +2 falling into merge conflict and repeatedly having to be rebased and re-reviewed, eating up more maintainer resources | 16:37 |
| fungi | the top challenges with reviewing were changes without a spec/blueprint, low-priority changes, and contributors failing to address review comments or ci failures | 16:37 |
| fungi | other comments included struggles in agreeing on automated tooling, and inconsistency of style/lint choices between different openstack teams | 16:37 |
| fungi | looking at metrics we gathered from gerrit for the past 5 development cycles, we saw caracal was particularly slow for reviews (also observed for cinder), not sure what the cause was but then things got somewhat better again in the past year | 16:37 |
| fungi | number of changes that don't get merged within a cycle were fairly steady over time except for epoxy where it spiked, and review times seemed consistent with contributor survey observations | 16:38 |
| fungi | finding some way to improve the time to first review might help keep contributors, new and established, involved and engaged | 16:38 |
| fungi | trying to balance out first review time between new/casual contributors and established team members/maintainers could also help | 16:38 |
| fungi | probably the biggest and most actionable suggestion to is better/clearer communication in reviews that are done, particularly increasing transparency with regard to change and spec prioritization | 16:38 |
| fungi | sorry, i know that's a pretty big info dump (i tried to pare it down as much as possible | 16:38 |
| fungi | if ildikov's around she might also have additional comments | 16:38 |
| fungi | also if anyone has questions, i'm happy to try and answer them either here in the meeting or in irc after | 16:39 |
| gibi | what my pretty tired mind got this from is: so basically we should say no to new specs early instead of approving them and then not reviewing the implementation in time | 16:40 |
| fungi | this is still just the beginning, we'll be continuing to run the surveys and refine some of the gerrit metrics we've been looking at | 16:40 |
| fungi | gibi: yes, that's a great insight. having some feel for what your future review bandwidth might be and keeping conservative about over-committing to feature work especially | 16:41 |
| gibi | then we will get the feedback that we are hostile for proposals | 16:41 |
| gmaan | I am sure the feedback for this will be 'nova stopped accepting new request/features' | 16:41 |
| gmaan | gibi: ++ | 16:41 |
| gibi | this is a very hard thing to balance | 16:41 |
| sean-k-mooney | im not sure if SLUPR effect impacted caracal. nova POCed the slurp process for yoga to antelope | 16:41 |
| sean-k-mooney | but caracal was the first offical one | 16:41 |
| fungi | i don't think it's out of line to say that the team has limited review bandwidth and is prioritizing fixing bugs over adding features | 16:42 |
| sean-k-mooney | nothing else specifcally jumpst out at me in that timeframe that made it special | 16:42 |
| fungi | slurp is a great guess there, i agree | 16:42 |
| ildikov | Apologies, I’m in transit, but trying to follow along and add comments if helpful | 16:43 |
| gmaan | I think one question should be included in survey that people who are not getting enough reviews do contribute in community/nova also ? if no then can they and improve the situation? | 16:43 |
| fungi | but on the spec prioritization subtopic, it still seems like being conservative about approving new specs and telling people there won't be time to review the changes for them (and ask for help fixing bugs and working toward becoing new maintainers) is still going to be a better experience for them than having their specs approved and then not being able to find anyone to | 16:44 |
| fungi | review the resulting changes | 16:44 |
| gmaan | it is always two way things and sometime I feel that collecting/providing one way feedback is not much helpful. We have been receiving this feedback since many years and I at least did not see any improvement due to that. | 16:45 |
| fungi | writing a spec and having it postponed or rejected is some wasted work, but writing the entire implentation and having it get ignored will leave an even worse taste in their mouths | 16:45 |
| gmaan | but maybe that is just me | 16:45 |
| gibi | I can limit my spec +2 on things where I commit to review the impl and only use my +1 on the rest of the specs | 16:46 |
| fungi | well, i see it as indicating where the project could use the most additional help, and also something maintainers can point to in order to explain why things people want aren't getting done | 16:46 |
| ildikov | I think transparent communication is key, as y’all are saying. I also think gmaan is touching on an important point regarding capturing more contributors to do reviews. | 16:46 |
| sean-k-mooney | we could try that but im not sure how much that will help | 16:46 |
| gibi | but it won't create satisfaction from the contributors as they feature will not land this way either | 16:46 |
| sean-k-mooney | that partly pickign yoru favorit rather then which isready | 16:47 |
| fungi | i also think satisfying ungrateful or entitled contributors isn't a goal, they're generally going to become a time sink, what would help is figuring out how to improve the experience for people who are likely to stick around and help | 16:48 |
| gibi | how do I foresee who will stick around and help? | 16:48 |
| fungi | and yeah, being able to tell the two apart isn't easy | 16:48 |
| gibi | yeah | 16:48 |
| gmaan | IMO, merging the spec is 'we welcome the ideas/feature requests' and if slow/no review in code then yes we face challenge in review bandwidth so help here | 16:48 |
| gibi | should we require one cycle of active bugfixing from someone before we review their spec? | 16:49 |
| sean-k-mooney | i guess folks that engagen in the review positivly and relfect on feedback | 16:49 |
| fungi | but, for example, people who pester me for reviews on things that have only been open a day or two? i tend to ignore them and their changes, or at most explain to them that their expectations are unrealistic | 16:49 |
| sean-k-mooney | is a good indication to some degree | 16:49 |
| fungi | (unless it's clear that the change is urgent for the project and not just for the person proposing it) | 16:49 |
| Uggla | maybe dumb question, the feedback are for nova or global for openstack project ? | 16:50 |
| fungi | what i outlined above was the result of looking at the handful of resurvey responses we received for nova, and nova-specific gerrit metrics | 16:50 |
| fungi | the posts on the mailing list are openstack-wide analysis | 16:50 |
| ildikov | +1 | 16:51 |
| dansmith | this sounds like the same feedback we've had for ten years to me | 16:51 |
| gmaan | yeah, maybe more than 10 :) | 16:51 |
| sean-k-mooney | fungi: i read the mailing list post and i think there is a simliar corratlation tbeween nova's feedback and the wider feedback | 16:51 |
| Uggla | fungi, thanks. What about other projects ? Same feelings about reviews ? | 16:51 |
| dansmith | I always chalk this up to people wanting to drive-by a fix with no tests, a spec with no promise of CI, or the hard work to refactor the things necessary to make it work for more than just their niche case | 16:53 |
| fungi | to some extent, yes, nova had lower overall numbers than other projects we looked at, though for the metrics i think a lot of that is due to outliers and "long tail" values skewing the averages, median values suggest there is still al lot of work getting done and there are more changes getting merged than propoosed each cycle, so the perceptions don't necessarily represent | 16:53 |
| fungi | reality in all cases | 16:53 |
| dansmith | and a decade of that sort of thing makes us fairly conservative in what we accept (code, not specs) | 16:53 |
| sean-k-mooney | we did have a cople of large feataures like manila shares that took 4-5 releases | 16:54 |
| dansmith | and we often get feedback that specs hold up implementation (even though they don't) so I think that's why some specs get approved even though we're not going to review the implementation | 16:54 |
| sean-k-mooney | nova ofthen has deps on other projects that can take a whiel to resolve | 16:54 |
| fungi | however, from what we can tell it seems like a small number of poor experiences can disproportionately influence contributors' perceptions of the whole | 16:54 |
| ildikov | Would seeing the metrics per release cycle help with evaluating what to do with the survey results? | 16:54 |
| dansmith | or people think that an approved spec means we won't object to the actual implementation | 16:54 |
| dansmith | sean-k-mooney: also that | 16:54 |
| ildikov | Like the time needed for first reviewed to happen, patches to get merged | 16:54 |
| sean-k-mooney | ildikov: maybe but im not sure how actionaable that data will be | 16:56 |
| fungi | yeah, we're at least initially trying to avoid dumping the project-specific analyses to the ml since we don't want it to turn into side-by-side comparisons and this-team-is-better-than-that-team sorts of discussions, but we can find a way to share more concrete numbers | 16:56 |
| dansmith | yeah, pretty meaningless to me | 16:56 |
| gibi | yeah, I would be more interested in case studies on specific contribution attempts | 16:57 |
| ildikov | sean-k-mooney: I understand. I was thinking to compare how long things take with what people’s impressions are. And see if there’s any that’s better or worse than what people had in mind. And then see which one we’re can help y’all figure out how to improve. | 16:57 |
| sean-k-mooney | knowing what the outliers were might help at least we could know if they should be excludied or were really a problem | 16:57 |
| ildikov | This isn’t something to solve in one meeting. But wet would like to help figure out how to make improvements. | 16:57 |
| sean-k-mooney | i.e. if it took 200days to merge but was teh 30th patch in a seriese that might mean the data shoudl be excluded | 16:58 |
| ildikov | And whether or not those actions are helping, or were should try smth e we else | 16:58 |
| fungi | i think it's also reasonable to ignore it all as "this is nothing we don't already know" but at least some feedback on what you'd like looked at (e.g. the idea of trying to gauge the contributor survey respondent's level of involvement in helping the project in other ways) is definitely appreciated | 16:58 |
| ildikov | I’ll look into the case study approach | 16:58 |
| sean-k-mooney | fungi: ildikov well i think the general trend are useful and if a project is vastly diffent then another hten it woudl be interesting to know why | 16:59 |
| dansmith | fungi: I'd also say "nothing we don't already know and have tried various things to address in the past, with minimal success" | 16:59 |
| sean-k-mooney | but i think part fo that comes down to the project in quetion too. | 16:59 |
| ildikov | Might not be for a meeting to discuss that, since we can’t make that anonymous, etc | 16:59 |
| dansmith | fungi: we've done all kinds of things like core sponsors, runways, etc.. | 16:59 |
| ildikov | sean-k-mooney: +1 | 16:59 |
| fungi | we've certainly done some case-by-case studies leading up to this (it started from specific member company representatives giving us lists of changes where they struggled and maybe gave up) | 16:59 |
| dansmith | specs themselves were sort of a solution to this problem in the first place, and they improved some things but introduced a hurdle that sometimes get complained about | 17:00 |
| fungi | part of the challenge is to avoid public shaming while finding ways to steer toward constructive feedback | 17:00 |
| ildikov | +1 | 17:00 |
| Uggla | We are on top of the hour. So can we wrap up ? | 17:00 |
| fungi | anyway, i didn't want to run over the end of the meeting | 17:01 |
| fungi | thanks! | 17:01 |
| gibi | ildikov fungi Thanks for the effort | 17:01 |
| fungi | i'm always around for more discussion after | 17:01 |
| dansmith | fungi: yep, appreciate that, because since this has been a complaint for over ten years, some of us are likely to feel like rage quitting :) | 17:01 |
| Uggla | ildikov, fungi, thanks | 17:01 |
| ildikov | We would love to avoid that! :) | 17:01 |
| ildikov | Thanks y’all! | 17:01 |
| Uggla | I wonder if we can postponed the open discussion to next week. There is a topic about Evacuate Action & InstanceInvalidState, but I don't know who entered it. | 17:02 |
| * gibi moves to the tc meeting... | 17:03 | |
| fungi | while it may be an unpopular approach, the way a lot of open source projects (particularly volunteer-run communities) approach that challenge is by just saying that complaining only serves to burn out the handful of people keeping things going, and to either help shoulder their burden or go away | 17:03 |
| Uggla | fungi++ completely true. | 17:04 |
| fwiesel | Uggla: That would be me. Then maybe two weeks? | 17:04 |
| fwiesel | In two weeks, I meant. | 17:05 |
| Uggla | fwiesel, yes I keep the items and we will discuss it not next week but the week after. | 17:05 |
| fwiesel | Uggla: Thanks. | 17:05 |
| gibi | fungi: yeah then we need to figure out how they can effectivel help shouldering the burden | 17:05 |
| Uggla | fwiesel, thanks you to understand. I don't want to keep people here anymore as we are already overtime. | 17:06 |
| Uggla | Thanks all | 17:07 |
| Uggla | #endmeeting | 17:07 |
| opendevmeet | Meeting ended Tue Jun 17 17:07:15 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 17:07 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-06-17-16.02.html | 17:07 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2025/nova.2025-06-17-16.02.txt | 17:07 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-06-17-16.02.log.html | 17:07 |
| gibi | Uggla: thanks | 17:07 |
| * sean-k-mooney wonder if we could block reset state from everyone in defualt policy liek cross cell migrate | 17:25 | |
| sean-k-mooney | ^ that actully a ligiitmate suggestion | 17:27 |
| sean-k-mooney | no mather how often we tell them ot never use it after a issue with a move operatiorn they still do | 17:27 |
| sean-k-mooney | if we made them opt into it or had a "allow_foot_guns" role it would avodi lot of reset-state related pain | 17:28 |
| sean-k-mooney | sort of like cephs --yes-i-really-mean-it flag to make them do just a littel bit more to do the unsafe thing | 17:29 |
| gibi | sean-k-mooney: I'm supportive | 17:29 |
| sean-k-mooney | i feel like if we do it will be a https://xkcd.com/1172/ and i tink im ok with that | 17:32 |
| gmaan | sean-k-mooney: seeing it is admin currently, it should be very noticeable that what they are doing but I will not be against of blocking it via policy. | 17:40 |
| gibi | sean-k-mooney: pretty much yes :) | 17:40 |
| gmaan | but I think we should remove it or restrict it in some separate seciton in api-ref | 17:41 |
| sean-k-mooney | gmaan: well changing the policy is the more consrevity change i actully want to deltee that api | 17:41 |
| gmaan | sean-k-mooney: I am up to delete it. I am not sure what all cases it was helpful but it can/has been distructive in many cases | 17:42 |
| sean-k-mooney | gmaan: i twas orgianlly added to help when your stuck in an intermediate state | 17:43 |
| sean-k-mooney | most of the time the fix is hard-reboot or delete dependign on the state | 17:43 |
| gmaan | yeah | 17:44 |
| sean-k-mooney | i.e. if your stuck in buildign then delete | 17:44 |
| sean-k-mooney | if we changed defautl policy we coudl get feedback form operators before commitign one way or another | 17:44 |
| sean-k-mooney | i added --auto-approve and made it request an interactive approve in osc recently https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/server.html#cmdoption-openstack-server-set-auto-approve | 17:46 |
| gmaan | sure, that will help at least to know if people want it or we can delete it. at least keep it restrictive for some cycles and if any one ask for it at least then it is not good to delete | 17:47 |
| sean-k-mooney | so not it at least asks you are you sure before it will do reset state | 17:47 |
| sean-k-mooney | s/not/now/ | 17:47 |
| gmaan | sean-k-mooney: yeah I saw that . ++ that was good from ux side | 17:47 |
| gmaan | sean-k-mooney: if dis-allow in policy, do we need to remove/change anything from client? or nova error about unauthorized is enough for admin to know what they need to do | 17:49 |
| gmaan | I want to avoid if it create confusion over error messgage or they think it is gone | 17:49 |
| sean-k-mooney | no it will just get a 401 of 403 | 17:53 |
| sean-k-mooney | same as any other policy error | 17:54 |
| sean-k-mooney | granted im not sure it will say its becuase of policy but it may | 17:54 |
| sean-k-mooney | i woudl have to check if we have a generic policy message that will be show to the end user. | 17:54 |
| sean-k-mooney | gmaan: i dont think we have any special client side code for cross cell resize witch is the only case we disallow everyone today | 17:55 |
| gmaan | cool | 17:56 |
| ozzzo | If I have VMs that were built with host-passthrough and now we are replacing hardware and we need to live-migrate to the new hypervisors, is it possible to make the new hypervisors emulate the old CPU so that live-migration can work? | 18:05 |
| sean-k-mooney | ozzzo: no not really | 18:05 |
| sean-k-mooney | if its actully compatible then the migration will jsut work form the old host to the new host | 18:06 |
| sean-k-mooney | but once the vm is rebooted on the new host it wont be able to move back | 18:06 |
| ozzzo | we tried it but the filter appears to be rejecting; it says "no valid host" | 18:06 |
| sean-k-mooney | host-passthrough at least the way it work in nova today exposed too much of the underlying host cpu details | 18:07 |
| ozzzo | This is in wallaby | 18:07 |
| sean-k-mooney | ya that woudl not fix it. what i was refering too is new livberit ahs a new semi-mode | 18:09 |
| sean-k-mooney | basiclly you can say host-passthough + live migratable | 18:10 |
| sean-k-mooney | which exposes a tiny bit less | 18:10 |
| sean-k-mooney | master cant do that today | 18:10 |
| sean-k-mooney | ozzzo: have you conisered cold migration instead | 18:10 |
| sean-k-mooney | did anyoen hwave time to look at my spec today by the way https://review.opendev.org/c/openstack/nova-specs/+/951222 | 18:11 |
| sean-k-mooney | i dont see any comment form others | 18:12 |
| sean-k-mooney | i still have -w on ti becaues i planned ot make some minor chagnes to wording but its been ready for review for 3 weeks now so im looking for some input on the general direction before inveting more time into it :) | 18:14 |
| sean-k-mooney | gibi: by the way i think its very possibel that we may end up supprotign diffent python versoin dependign on if eventlet is enabeld or not next cycle | 18:23 |
| sean-k-mooney | i.e. we may only supprot 3.13 in threaded mode | 18:24 |
| sean-k-mooney | and not supprot it in eventlet mode ever if eventlet does not get fixed | 18:24 |
| sean-k-mooney | our unit and fucntional test run fine under 3.13 | 18:24 |
| sean-k-mooney | regardless of eventlet so that unfrotuently does not help us... | 18:25 |
| sean-k-mooney | i think thats because of how our fixture work with regards ot things like the neutron client | 18:25 |
| ozzzo_home | @sean-k-mooney: That's what I was hoping to avoid; this is a prod region, but it looks like TINA | 21:23 |
| sean-k-mooney | ozzzo_home: there is one thing you could try. | 21:34 |
| sean-k-mooney | ozzzo_home:nova is a littel stricter then libvirt in how we compare the compatiabltiyof the cpus | 21:34 |
| sean-k-mooney | ozzzo_home: you could enable https://docs.openstack.org/nova/latest/configuration/config.html#workarounds.skip_cpu_compare_on_dest | 21:35 |
| sean-k-mooney | this will disable novas cpu compatiablity check in pre live migrate | 21:35 |
| sean-k-mooney | and fall back to libvirts one in migrate | 21:35 |
| sean-k-mooney | its more expensive to do that which is why we dont rely on it | 21:36 |
| ozzzo_home | ok I'll try it, ty! | 21:36 |
| sean-k-mooney | bug its somethign you could try at least for a short period of time to move insteas to the new hardway | 21:36 |
| sean-k-mooney | *hardware | 21:36 |
| sean-k-mooney | tehre are are few other related options just below it | 21:37 |
| sean-k-mooney | like https://docs.openstack.org/nova/latest/configuration/config.html#workarounds.skip_hypervisor_version_check_on_lm | 21:37 |
| sean-k-mooney | we dont actully allow moving form a newer livirt/qemu to and older one but you can turn that off | 21:37 |
| sean-k-mooney | you can also turn off the startup cpu comaptibaltiy check https://docs.openstack.org/nova/latest/configuration/config.html#workarounds.skip_cpu_compare_at_startup | 21:38 |
| sean-k-mooney | again i dont advice doing that as you will only findout yoru config is wrong when you try to boot a vm | 21:38 |
| sean-k-mooney | but in very rare cases those can be sueful for working around libvirt bugs | 21:38 |
| sean-k-mooney | or upgrade issues | 21:38 |
| sean-k-mooney | skip_cpu_compare_on_dest is your best bet | 21:39 |
| ozzzo_home | sean-k-mooney: Will that work in Wallaby? I don't find it in the wallaby doc | 22:03 |
| -opendevstatus- NOTICE: Zuul jobs reporting POST_FAILURE were due to an incident with one of our cloud providers; this provider has been temporarily disabled and changes can be rechecked | 22:37 | |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!