Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-06-24
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.

Earlier   Later