| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-06-17 | |||
| 16:51:20 | gmaan | yeah, maybe more than 10 :) | |
| 16:51:28 | 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:43 | Uggla | fungi, thanks. What about other projects ? Same feelings about reviews ? | |
| 16:53:22 | 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:27 | 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:29 | fungi | reality in all cases | |
| 16:53:52 | dansmith | and a decade of that sort of thing makes us fairly conservative in what we accept (code, not specs) | |
| 16:54:07 | sean-k-mooney | we did have a cople of large feataures like manila shares that took 4-5 releases | |
| 16:54:21 | 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:24 | sean-k-mooney | nova ofthen has deps on other projects that can take a whiel to resolve | |
| 16:54:27 | 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:32 | ildikov | Would seeing the metrics per release cycle help with evaluating what to do with the survey results? | |
| 16:54:37 | dansmith | or people think that an approved spec means we won't object to the actual implementation | |
| 16:54:47 | dansmith | sean-k-mooney: also that | |
| 16:54:48 | ildikov | Like the time needed for first reviewed to happen, patches to get merged | |
| 16:56:01 | sean-k-mooney | ildikov: maybe but im not sure how actionaable that data will be | |
| 16:56:19 | 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:21 | dansmith | yeah, pretty meaningless to me | |
| 16:57:08 | gibi | yeah, I would be more interested in case studies on specific contribution attempts | |
| 16:57:24 | 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:43 | 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:51 | ildikov | This isn’t something to solve in one meeting. But wet would like to help figure out how to make improvements. | |
| 16:58:13 | ildikov | And whether or not those actions are helping, or were should try smth e we else | |
| 16:58:13 | 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:28 | 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:55 | ildikov | I’ll look into the case study approach | |
| 16:59:06 | 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:15 | 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:26 | sean-k-mooney | but i think part fo that comes down to the project in quetion too. | |
| 16:59:30 | ildikov | Might not be for a meeting to discuss that, since we can’t make that anonymous, etc | |
| 16:59:40 | dansmith | fungi: we've done all kinds of things like core sponsors, runways, etc.. | |
| 16:59:52 | 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:52 | ildikov | sean-k-mooney: +1 | |
| 17:00:15 | 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:24 | fungi | part of the challenge is to avoid public shaming while finding ways to steer toward constructive feedback | |
| 17:00:53 | ildikov | +1 | |
| 17:00:59 | Uggla | We are on top of the hour. So can we wrap up ? | |
| 17:01:04 | fungi | anyway, i didn't want to run over the end of the meeting | |
| 17:01:07 | fungi | thanks! | |
| 17:01:11 | gibi | ildikov fungi Thanks for the effort | |
| 17:01:16 | fungi | i'm always around for more discussion after | |
| 17:01:17 | 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:41 | Uggla | ildikov, fungi, thanks | |
| 17:01:44 | ildikov | We would love to avoid that! :) | |
| 17:01:59 | ildikov | Thanks y’all! | |
| 17:02:57 | 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:03:44 | 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:04:24 | Uggla | fungi++ completely true. | |
| 17:04:48 | fwiesel | Uggla: That would be me. Then maybe two weeks? | |
| 17:05:00 | fwiesel | In two weeks, I meant. | |
| 17:05:36 | Uggla | fwiesel, yes I keep the items and we will discuss it not next week but the week after. | |
| 17:05:48 | fwiesel | Uggla: Thanks. | |
| 17:05:52 | gibi | fungi: yeah then we need to figure out how they can effectivel help shouldering the burden | |
| 17:06:50 | Uggla | fwiesel, thanks you to understand. I don't want to keep people here anymore as we are already overtime. | |
| 17:07:02 | Uggla | Thanks all | |
| 17:07:15 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-06-17-16.02.log.html | |
| 17:07:15 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2025/nova.2025-06-17-16.02.txt | |
| 17:07:15 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-06-17-16.02.html | |
| 17:07:15 | 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:15 | Uggla | #endmeeting | |
| 17:07:18 | gibi | Uggla: thanks | |
| 17:27:08 | sean-k-mooney | ^ that actully a ligiitmate suggestion | |
| 17:27:29 | 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:28:30 | 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:29:26 | 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:38 | gibi | sean-k-mooney: I'm supportive | |
| 17:32:34 | 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:40:45 | 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:53 | gibi | sean-k-mooney: pretty much yes :) | |
| 17:41:06 | gmaan | but I think we should remove it or restrict it in some separate seciton in api-ref | |
| 17:41:53 | sean-k-mooney | gmaan: well changing the policy is the more consrevity change i actully want to deltee that api | |
| 17:42:33 | 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:43:02 | sean-k-mooney | gmaan: i twas orgianlly added to help when your stuck in an intermediate state | |
| 17:43:53 | sean-k-mooney | most of the time the fix is hard-reboot or delete dependign on the state | |
| 17:44:01 | gmaan | yeah | |
| 17:44:04 | sean-k-mooney | i.e. if your stuck in buildign then delete | |
| 17:44:47 | sean-k-mooney | if we changed defautl policy we coudl get feedback form operators before commitign one way or another | |
| 17:46:41 | 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:47:25 | 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:30 | sean-k-mooney | so not it at least asks you are you sure before it will do reset state | |
| 17:47:44 | sean-k-mooney | s/not/now/ | |
| 17:47:49 | gmaan | sean-k-mooney: yeah I saw that . ++ that was good from ux side | |
| 17:49:32 | 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:58 | gmaan | I want to avoid if it create confusion over error messgage or they think it is gone | |
| 17:53:44 | sean-k-mooney | no it will just get a 401 of 403 | |
| 17:54:00 | sean-k-mooney | same as any other policy error | |
| 17:54:16 | sean-k-mooney | granted im not sure it will say its becuase of policy but it may | |
| 17:54:37 | sean-k-mooney | i woudl have to check if we have a generic policy message that will be show to the end user. | |
| 17:55:25 | 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:56:22 | gmaan | cool | |
| 18:05:11 | 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:50 | sean-k-mooney | ozzzo: no not really | |
| 18:06:13 | sean-k-mooney | if its actully compatible then the migration will jsut work form the old host to the new host | |
| 18:06:24 | sean-k-mooney | but once the vm is rebooted on the new host it wont be able to move back | |
| 18:06:58 | ozzzo | we tried it but the filter appears to be rejecting; it says "no valid host" | |
| 18:07:00 | 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:13 | ozzzo | This is in wallaby | |
| 18:09:47 | sean-k-mooney | ya that woudl not fix it. what i was refering too is new livberit ahs a new semi-mode | |
| 18:10:02 | sean-k-mooney | basiclly you can say host-passthough + live migratable | |
| 18:10:09 | sean-k-mooney | which exposes a tiny bit less | |