16:01:44 <Uggla> #startmeeting nova
16:01:44 <opendevmeet> Meeting started Tue Jun 24 16:01:44 2025 UTC and is due to finish in 60 minutes.  The chair is Uggla. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:44 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:44 <opendevmeet> The meeting name has been set to 'nova'
16:01:53 <Uggla> Hello everyone
16:02:24 <bauzas> o/
16:02:31 <elodilles> o/
16:02:41 * bauzas hopes that one day, AI bubble will just explode
16:02:54 <andreykurilin> O/
16:02:57 <bauzas> the quickier being the better
16:03:11 <gibi> o/
16:03:16 <bauzas> (sorry, was a rant)
16:03:21 <gibi> bauzas: it will
16:03:27 <Uggla> bauzas ;)
16:03:45 <Uggla> #topic Bugs (stuck/critical)
16:03:52 <Uggla> #info No Critical bug
16:04:08 <gibi> the question is where we will be when that bubble bursts
16:04:22 <Uggla> #topic Gate status
16:04:33 <Uggla> #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs
16:04:40 <Uggla> #link https://etherpad.opendev.org/p/nova-ci-failures-minimal
16:04:47 <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:57 <Uggla> #info Please look at the gate failures and file a bug report with the gate-failure tag.
16:05:03 <Uggla> #info Please try to provide meaningful comment when you recheck
16:05:42 <Uggla> jumping to next topic because gmaan is not available.
16:05:46 <Uggla> #topic Release Planning
16:05:53 <Uggla> #link https://releases.openstack.org/flamingo/schedule.html
16:05:59 <Uggla> #info Nova deadlines are set in the above schedule
16:06:19 <Uggla> #info Nova Spec review day was last week.
16:06:46 <bauzas> we have one week before the spec freeze
16:06:57 <bauzas> let's be productive :)
16:07:01 <Uggla> I'm not sure we managed to review a lot of them. As I think everybody was busy.
16:07:28 <Uggla> bauzas, You are right spec freeze is July 3rd
16:07:30 <gibi> do we want to impose a limit how much we approve based on how much bandwidth we have to review implementation?
16:07:55 <bauzas> good call, last time (Epoxy) I was figuring this wasn't needed due to the low level of approved ones
16:08:03 <bauzas> what's the current state of approved specs ?
16:08:44 <Uggla> bauzas, I'm not up2date with it. :(
16:08:50 <ratailor> How can I get reviews for https://review.opendev.org/q/topic:%22bp/show-instance-action-finish-time%22 which is already completed.
16:08:51 <fungi> that did seem like one of the upshots of the btg topic discussion too, approving a reasonable number of specs helps to not set unrealistic expectations for the people who might submit changes to implement them
16:10:30 <bauzas> https://specs.openstack.org/openstack/nova-specs/specs/2025.2/
16:10:41 <bauzas> I see 7 approved
16:10:52 <bauzas> but I can't recall whether we approved specless bps
16:11:00 <sean-k-mooney> we have
16:11:08 <sean-k-mooney> not a lot but one or two
16:11:08 <gibi> eventlet removal is a specless bp
16:11:14 <sean-k-mooney> i think thsoe are all done
16:11:19 <Uggla> we have also some specless BP.
16:11:19 <sean-k-mooney> well expcte eventlet
16:11:22 <bauzas> that would put the number to a small 10
16:11:41 <sean-k-mooney> im not sure we shoudl set a numerical limit
16:11:54 <bauzas> I'd assume that we have a room for not more than 5 or 6 but usually we only merge ~12 features per cycle
16:12:01 <sean-k-mooney> i prefered gibis suggestion last week or +1 isntead of +2
16:12:05 <sean-k-mooney> if you dont plan to review
16:12:08 <bauzas> so that's really a messaging
16:12:20 <bauzas> messaging question
16:12:42 <gibi> yeah I applied that last week on some specs
16:13:21 <bauzas> the real ask here is whether we want to paperwork some capacity limits while we never did before
16:13:50 <bauzas> but about the btg discussion, it has a cost : people could consider that we're committed to review their implementation, which isn't the case
16:13:56 <sean-k-mooney> if we had one i woudl likely be forece to downgrade some of my +2s to +1s we can condier it next cycle
16:14:05 <sean-k-mooney> but i dont want to chagne things this cycle at this point
16:14:06 <gibi> I think if each core is only +2 a spec if they promise to review the impl then there will be a natural emergent limt
16:14:25 <bauzas> I still want to review a couple of left specs that I got interested by
16:15:09 <bauzas> gibi: we somehow approached that on the previous PTG but we never enforced such rule yet
16:15:30 <Uggla> I agree gibi, that's probably a good method.
16:15:58 <bauzas> but we're in the middle of the acceptance process
16:17:07 <gibi> sure I don't suggest to go back and change +2s (but could be if you want) but going forward we can be limiting +2s
16:17:10 <bauzas> I mean, I'm not opposed to that, but there are precedent specs that we approved
16:18:13 <bauzas> anyway, if you feel so, do so
16:18:29 <bauzas> I'll personnally follow that rule too
16:19:44 <sean-k-mooney> i really dont want to change the rules this cycle
16:20:24 <sean-k-mooney> this is all valid for next cycle but i think its unfair to change the critiria mid way. (removing +2s)
16:20:56 <sean-k-mooney> that up to each reviewer
16:21:05 <sean-k-mooney> but i htink taht would send lot of mixed messages
16:21:19 <sean-k-mooney> we only have 9? days till spec freeze
16:21:43 <sean-k-mooney> if folks want to not add a +2 or +1 to open spec that totally fair
16:22:10 <bauzas> that's why I'm saying : as we don't have quorum now, let's just leave that to each core's opinion
16:22:19 <sean-k-mooney> +1
16:23:14 <Uggla> +1, I think it will be ok, based on the time left.
16:23:26 <Uggla> Moving on.
16:23:39 <gibi> OK
16:23:48 <Uggla> #topic Review priorities
16:23:54 <Uggla> #link https://etherpad.opendev.org/p/nova-2025.2-status
16:24:42 <Uggla> I think we should pay attention to this one: https://review.opendev.org/c/openstack/nova-specs/+/951636
16:26:38 <Uggla> #topic OpenAPI
16:26:45 <Uggla> #link: https://review.opendev.org/q/topic:%22openapi%22+(project:openstack/nova+OR+project:openstack/placement)+-status:merged+-status:abandoned
16:27:21 <Uggla> #info 25 increase +5, there are new ones from Stephen.
16:27:45 <sean-k-mooney> yep
16:27:51 <sean-k-mooney> im making my way through them
16:28:02 <sean-k-mooney> several are fixu ups form minor issues earlier in the series
16:28:26 <Uggla> sean-k-mooney, you are right there are FUP in the list.
16:29:00 <sean-k-mooney> there are currnetly about 10 queued to merge
16:29:23 <sean-k-mooney> im kind of brunt on them for tosay but im planning to loop back again later in the week
16:30:01 <Uggla> sean-k-mooney 👍
16:30:22 <Uggla> Moving on because time is flying.
16:30:22 <sean-k-mooney> i think gmaan  has done a first pass on all the currently open ones or most of them and Uggla  has reviewds many fo them too
16:30:37 <Uggla> #topic Stable Branches
16:30:37 <sean-k-mooney> so ya good progress but we can move on
16:30:51 <Uggla> elodilles, the mic is yours
16:30:56 <elodilles> thanks Uggla
16:31:11 <elodilles> as in the past weeks, there's nothing special to report
16:31:18 <elodilles> #info stable branches (stable/2025.1 and stable/2024.*) seem to be in OK state
16:31:25 <elodilles> #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci
16:31:36 <elodilles> that's all, back to you Uggla
16:31:41 <Uggla> thx elodilles
16:32:27 <Uggla> Skipping next topic because fwiesel is not available
16:32:33 <Uggla> #topic Gibi's news about eventlet removal.
16:32:38 <Uggla> #link Blog: https://gibizer.github.io/categories/eventlet/
16:32:47 <Uggla> #link nova-scheduler series is ready for core review, starting at https://review.opendev.org/c/openstack/nova/+/947966
16:32:57 <Uggla> gibi, something you want to share.
16:33:05 <gibi> hm
16:33:06 <gibi> sorry
16:33:13 <gibi> thanks for the feedback on the series
16:33:28 <gibi> I spent time on https://review.opendev.org/c/openstack/nova/+/953121
16:33:39 <gibi> that was triggered by the discusson on the spawn_on patch
16:33:56 <gibi> I have local changes to apply some of those to the eventlet series itself
16:34:11 <gibi> but downstream priorities stole my time
16:34:17 <bauzas> gibi: I saw the -W, can I start to review it tho ?
16:34:30 <bauzas> (I mean the spawn_on patch)
16:34:35 <gibi> bauzas: you can it is not broken. There is a missing piece that I will add
16:34:41 <gibi> all noted in the review comments
16:35:01 <gibi> to be precise I will add a missing test piece
16:35:06 <gibi> not production code piece
16:35:14 <bauzas> ack
16:35:36 <gibi> and
16:35:48 <gibi> there is the governance discussion about when to drop eventlet
16:36:00 <gibi> honestly I'm a bit lost how to move that forward
16:36:23 <gibi> https://review.opendev.org/c/openstack/governance/+/952903/1/goals/selected/remove-eventlet.rst
16:36:42 <gibi> I hope the tc has plans to reconcile the discussion there ;)
16:36:47 <gibi> that is it form me
16:36:57 <Uggla> thx gibi
16:37:06 <Uggla> #topic Open discussion
16:37:12 <Uggla> We have 2 topics
16:37:22 <Uggla> #topic (andreykurilin) Expansion of "servers:detail:get_all_tenants" policy to other server read-only APIs (example: https://review.opendev.org/c/openstack/nova/+/952896)
16:37:32 <Uggla> andreykurilin, please go ahead
16:37:44 <andreykurilin> Hi folks!
16:38:06 <andreykurilin> I, as an operator, have a need to provide readonly access to compute resources for third-party teams
16:38:24 <andreykurilin> While list api works fine, get api provides much better UX
16:38:52 <andreykurilin> What do you think about extending current readonly apis to reuse existing policy?
16:39:23 <andreykurilin> Does it need new api micro version ? Spec? Blueprint?
16:40:40 <sean-k-mooney> one of the latter two but policy change generally dont need micro verions
16:41:57 <sean-k-mooney> we do have a spec, two in fact for the intorduction fo the manager role and service role to nova
16:42:13 <sean-k-mooney> if i recall form the mailing list dicussion you only wanted to expose 1 endpoint correct
16:42:22 <sean-k-mooney> if it was many then i would say it needs a spec
16:42:49 <andreykurilin> Yes, I need get server api exposed. Maybe server actions in future, but not at this moment
16:43:42 <Uggla> It seems gmann is not opposed to the change, which is a good sign.
16:44:26 <andreykurilin> I’m happy to commit some resources to cover more than is needed for my company, if you want, but not sure that I have enough resources to work on a big spec
16:45:00 <Uggla> I think the question is  if we are ok to fix it as bug
16:46:32 <Uggla> sean-k-mooney any thought about that ?
16:47:42 <sean-k-mooney> i dont consider it a bug in teh backport sense. we could treat it as an RFE bug i.e. a bug with the rfe tag instead of a specless bluepirnt
16:48:23 <sean-k-mooney> i would suggest that if we want to do somethign this clcye we keep it small and targeted
16:48:45 <sean-k-mooney> and we can dicuss larger changes but in the context of next cycle
16:49:03 <sean-k-mooney> just being practical we hae several large api serises in flight
16:49:32 <sean-k-mooney> openapi scemea, service role and manger role
16:50:00 <sean-k-mooney> we may be ableo to review a targed patch but if you want to do many endpoint we will need more time to discss it then we have before m2
16:50:08 <Uggla> Tbh, I would rather have a specless BP. Easier to track on my side.
16:50:23 <andreykurilin> I’m ok to have only one endpoint “fixed” this cycle
16:50:45 <andreykurilin> Creating a specless BP works for me
16:50:54 <Uggla> So andreykurilin, if you can open a specless BP so I could track it.
16:50:55 <sean-k-mooney> then i woudl suggest filing a specless blueprint for server show
16:51:13 <Uggla> 👍
16:51:19 <sean-k-mooney> and then asking for it to be approved on the mailing list or next meeting
16:51:25 <sean-k-mooney> to give gmaan  or other type to respond
16:51:37 <andreykurilin> Ok, got it. Thank you
16:51:40 <sean-k-mooney> s/type/time/
16:52:03 <gmaan> I am ok for the spec-less BP and agree that it does not need microversion
16:52:17 <sean-k-mooney> im ok with that direction too
16:52:27 <sean-k-mooney> just for the metting ^
16:52:54 <gmaan> I tried to search history why we did not do for SHOW server when doing for details and could not find any reason
16:53:04 <gmaan> it was just not needed by anyone till now
16:53:52 <andreykurilin> It was “workaroundable”. We lived with list + id filter for several years already and finally I found time to ask you guys about this
16:54:07 <gmaan> ++, thanks for bringing that
16:54:14 <Uggla> andreykurilin++
16:55:20 <Uggla> moving on to next topic.
16:55:25 <Uggla> #topic (ratailor) spec and implementation for show-instance-action-finish-time (https://review.opendev.org/q/topic:%22bp/show-instance-action-finish-time%22)
16:55:40 <Uggla> ratailor please go ahead.
16:56:08 <ratailor> As the implementation is also completed, just a request to provide feedback on spec so that it gets merged before FF.
16:56:17 <opendevreview> Merged openstack/nova master: api: Add response body schemas for server IPs APIs  https://review.opendev.org/c/openstack/nova/+/937608
16:57:48 <ratailor> That's all from my side re this.
16:58:30 <sean-k-mooney> ratailor: do you have tempest coverage showing that this works ?
16:59:04 <sean-k-mooney> specificly it would be nice to see the test that orginally demponstrated this did not work passing
16:59:23 <ratailor> sean-k-mooney, don't have tempest tests yet, but I can try to submit chagne for that.
16:59:40 <ratailor> sean-k-mooney, yes, sure. I will try with that one.
16:59:40 <sean-k-mooney> https://review.opendev.org/c/openstack/tempest/+/905130
17:00:04 <sean-k-mooney> it woudl be nice to update that and have it depend on your seriese to show ti workign end to end
17:00:31 <ratailor> sean-k-mooney, sure. Thansk!
17:00:37 <Uggla> sean-k-mooney, I agree it might also help on an escalation we have internaly
17:03:11 <Uggla> We have 2 more topics, but we are also at the top of the hour. So gibi, jonnyb if you don't mind we would be able to discuss next week. Except if it's urgent.
17:03:26 <jonnyb> hi, fine for me
17:03:36 <Uggla> jonnyb, thx for your understanding
17:03:44 <Uggla> gibi ?
17:04:14 <sean-k-mooney> jonnyb: you wanted to add a tiny weigher right?
17:04:25 <jonnyb> yeah right
17:04:50 <sean-k-mooney> if you have the patch it woudl be good for other to at least condier it before the next meeting
17:04:59 <sean-k-mooney> or perhaps start a mailing list thread on the topic
17:05:16 <sean-k-mooney> tl;dr is it weighs host by how old they are
17:05:23 <sean-k-mooney> and prefers the newer ones
17:05:43 <jonnyb> its a pretty simple patch
17:05:48 <sean-k-mooney> which is similer but differnt to the hyperviors_version weigher and they both complement each other
17:06:24 <sean-k-mooney> im generally ok with this as a specless blueprint by the way but we can disscuss that outside teh meeting or next week
17:07:02 <gibi> Uggla: no worries my topic was touched during the eventlet block
17:07:14 <jonnyb> I can move this to the mailing list to not drag this out here. thanks
17:07:48 <Uggla> jonnyb, that will be ok next week, I guess it will not take long.
17:07:58 <Uggla> anyway time to close.
17:08:03 <Uggla> Thanks all
17:08:16 <Uggla> #endmeeting