16:01:45 <bauzas> #startmeeting nova
16:01:45 <opendevmeet> Meeting started Tue Jan 14 16:01:45 2025 UTC and is due to finish in 60 minutes.  The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:45 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:45 <opendevmeet> The meeting name has been set to 'nova'
16:01:49 <bauzas> heyho
16:01:52 <fwiesel> \o
16:02:01 <masahito> o/
16:02:02 <bauzas> #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting
16:02:13 <s3rj1k> hi all
16:03:14 <elodilles> o/
16:03:15 <Uggla> o/
16:03:26 <bauzas> (on a meeting but I can run)
16:05:06 <bauzas> #topic Bugs (stuck/critical)
16:05:44 <bauzas> #info No Critical bug
16:05:49 * gibi wanders in late
16:05:50 <bauzas> #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster
16:05:57 <bauzas> any bug report to discuss ?
16:06:39 <bauzas> looks not
16:06:49 <masahito> If there is a time, I want to talk this bug in the review priority topic. https://bugs.launchpad.net/nova/+bug/2085709
16:06:50 <bauzas> #topic Gate status
16:07:02 <bauzas> masahito: sure, I'll ping you at that time
16:07:12 <masahito> thank you.
16:07:37 <bauzas> #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs
16:07:44 <bauzas> #link https://etherpad.opendev.org/p/nova-ci-failures-minimal
16:07:57 <bauzas> #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:08:03 <bauzas> #info Please look at the gate failures and file a bug report with the gate-failure tag.
16:08:10 <bauzas> #info Please try to provide meaningful comment when you recheck
16:08:46 <opendevreview> Lajos Katona proposed openstack/nova master: blueprint: iothreads-for-instances  https://review.opendev.org/c/openstack/nova/+/939254
16:09:54 <bauzas> periodic jobs are all green
16:10:01 <bauzas> any gate failure to report ?
16:12:19 <bauzas> okay moving on
16:14:02 <bauzas> #topic Release Planning
16:14:09 <bauzas> #link https://releases.openstack.org/epoxy/schedule.html
16:14:16 <bauzas> #info Nova deadlines are set in the above schedule
16:14:53 <bauzas> #info 6 weeks before Feature Freeze
16:14:59 <bauzas> #info we'll try to create as os-traits release by the next 2 weeks, please provide your os-traits patches sooner than later.
16:15:02 <bauzas> you know this
16:16:09 <bauzas> #topic Review priorities
16:16:16 <bauzas> #link https://etherpad.opendev.org/p/nova-2025.1-status
16:16:29 <bauzas> #action bauzas to update the etherpad with the latest changes
16:16:40 <bauzas> masahito: you had an itemù
16:16:52 <masahito> Thanks.
16:17:09 <masahito> I added two bugs in the bottom of the etherpad page.
16:17:29 <masahito> https://bugs.launchpad.net/nova/+bug/2075100 and https://bugs.launchpad.net/nova/+bug/2085709
16:17:48 <masahito> The second one is a bug patch I mentioned before.
16:17:53 <gibi> masahito: I'm wondering if you problem is related to https://review.opendev.org/c/openstack/nova/+/932669 that fixed a freeze
16:18:42 <masahito> gibi: thanks, let me check. I didn't notice the patch.
16:20:05 <masahito> It looks like C or later release has the problem that long running thread blocks other thread operation because of libvirt connection.
16:21:53 <bauzas> masahito: okay, that's good that you added both fixes, we'll try to review them
16:23:03 <bauzas> can we move on ?
16:23:29 <masahito> I'm ok, thank you.
16:25:07 <bauzas> ack
16:25:15 <bauzas> #topic Stable Branches
16:25:24 <bauzas> elodilles: do you have anything ?
16:25:29 <elodilles> #info nothing to report, stable gates seem to be healthy
16:25:43 <elodilles> #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci
16:25:53 <elodilles> that's all from me
16:26:38 <bauzas> cool
16:27:45 <bauzas> #topic vmwareapi 3rd-party CI efforts Highlights
16:27:54 <fwiesel> No updates from my side
16:27:54 <bauzas> fwiesel: anything on your side ?
16:27:56 <bauzas> cool
16:28:03 <bauzas> #topic Open discussion
16:30:06 <bauzas> nothing on the agenda, anything else ?
16:30:10 <masahito> If time is allowed, I want to hear your opinion for this spec, too https://review.opendev.org/c/openstack/nova-specs/+/937587
16:30:50 <masahito> According to the gibi's comment, it's a bug not a new feature.  We're wondering the spec approval is needed or not.
16:32:40 <bauzas> unfortunately, we're post spec approval deadline
16:32:50 * bauzas opens the link
16:34:15 <bauzas> hmmmm
16:34:19 <masahito> yes, that's why I asked the question. If it's a bug, we can push bug fix for the problem, IIUC. But it's defined as a new feature, we'll wait the next development cycle.
16:34:23 <bauzas> I don't have that context in mind
16:34:58 <bauzas> sean-k-mooney: about https://review.opendev.org/c/openstack/nova-specs/+/937587/2/specs/2025.1/approved/add-mutual-prefix.rst, do you think like gibi that's just a placement bug ?
16:35:14 <gibi> not a placement one but a nova one :)
16:35:47 <bauzas> because that's nova which knows that, I see
16:35:49 <bauzas> you're right
16:36:30 <bauzas> so we should do something like set(new_traits) - set(existing_traits) to calculate the ones that should be deleted
16:36:47 <bauzas> and if we don't do that for custom traits, I agree with you that's a bug
16:37:02 <bauzas> because operators expect to only get custom traits that they pass
16:37:08 <gibi> it is more like nova always generates the list of expected traits internally for the RP and then it just need to sync it with placement to overwrite what is there
16:38:01 <gibi> I think nova never allowed outside users to add traits to RPs that is owned by nova, I expect that nova overwrites the extra traits during the periodic.
16:38:24 <gibi> for some reason from the spec text it seem it is not the case for the traits from the provider.yaml
16:38:29 <sean-k-mooney> reading back
16:38:35 <gibi> so when those removed from the .yaml they are not removed from the RP
16:38:55 <gibi> I did not looked at the code to get a better picture
16:39:06 <sean-k-mooney> ah we dont clean them up
16:39:10 <bauzas> yes
16:39:16 <sean-k-mooney> i guess tha tmakes sense becuase we dont know who added them
16:39:27 <bauzas> and the question is : is that behavior expected or not ? (to not clean them up)
16:39:31 <masahito> yes, current behavior is one way, only adding a listed trait to the RP.
16:39:58 <sean-k-mooney> it could be exetned to do clean up but that more a new feature then a bug
16:40:17 <sean-k-mooney> i think we just left it out of scope
16:40:23 <sean-k-mooney> for the inital spec
16:40:29 <gibi> sean-k-mooney: but I expect nove to only overwrite any traits on the RP with its own list
16:40:30 <sean-k-mooney> im not sure wha tthe best way to do that owuld be
16:40:54 <gibi> do not try to mix and match traits from the RP and from it internal state
16:40:57 <sean-k-mooney> well no we supprot people usign the placment api to add traits to an rp
16:41:25 <bauzas> we have two possibilities here
16:41:29 <sean-k-mooney> so nova cant nessiarly remove custom traits
16:41:35 <gibi> then why we have provider.yamls? I assumed that provider.yamls was needed in the first place to make the trait addition work
16:41:36 <sean-k-mooney> it can remove standard traits
16:41:54 <bauzas> either we say this sounds something we need to design, and then it will be discussed for F
16:41:57 <sean-k-mooney> no it was needed ot have a declaritive way to do that
16:42:19 <sean-k-mooney> i think this need more discussion then we have time for in this meeting
16:42:22 <bauzas> or we say that the expected behavior is understood and then that series is just bugfix
16:42:47 <bauzas> if so, sounds to me a design discussion which resolves to => move to F
16:43:04 <sean-k-mooney> my perspecitive is that CUSTOM traits cna be added/remove via the api or declaritivly, standard triaits are managed by the virt driver
16:43:25 <sean-k-mooney> so the fact the custom trait is not removed is expected based on that view point
16:43:56 <sean-k-mooney> however i agree we coudl recored which traits came form the provider.yaml in some form and enable nova to clean them up
16:44:06 <sean-k-mooney> that woudl be a new functionaltiy however not a bug
16:45:50 <sean-k-mooney> im not sold on the idea of teh mutal_prefix propsoed in the current spec
16:46:45 <sean-k-mooney> its an approch but im not sure its the best approch
16:47:10 <bauzas> then, as said, we're post spec freeze, this would be discussed on the Foxtrot PTG
16:47:49 <gibi> *Flamingo
16:47:55 <bauzas> I know
16:47:57 <gibi> ;]
16:48:04 <masahito> :)
16:48:48 <bauzas> anyway, I guess we unfortunately need to move that spec to that cycle
16:48:54 <masahito> I see the conclusion. Looks like lots of approach and design discussion are there.
16:49:27 <bauzas> masahito: are you OK with that ? this doesn't mean we couldn't discuss that before Flamingo (meh) but we will only accept it when it's there
16:50:29 <masahito> yup. One question is any extra discussion on the spec is also blocked by the F release PTG?
16:50:40 <sean-k-mooney> no
16:50:45 <sean-k-mooney> we can continue ot disucss
16:50:53 <masahito> Got it.
16:50:54 <sean-k-mooney> jus tmove the spec file to the correct release folder
16:51:47 <bauzas> thanks masahito for understanding
16:51:52 <masahito> I see there is two approach is there for the provider.yaml behavior in the meeting. We;ll update the spec including the topic.
16:52:04 <bauzas> ++
16:53:18 <bauzas> okay, I guess it's time for closing the meeting
16:53:21 <bauzas> anything anyone ?
16:53:50 <tkajinam> I have one but I can first discuss it with a few people after the meeting is finished.
16:54:30 <bauzas> cool
16:54:33 <tkajinam> and bring it again to the meeting next week if needed
16:54:40 <bauzas> ++ then, thanks all
16:54:44 <bauzas> #endmeeting