16:00:18 <bauzas> #startmeeting nova
16:00:18 <opendevmeet> Meeting started Tue Apr 23 16:00:18 2024 UTC and is due to finish in 60 minutes.  The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:18 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:18 <opendevmeet> The meeting name has been set to 'nova'
16:00:24 <bauzas> #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting
16:00:28 <bauzas> hey folks
16:00:36 <dansmith> o/
16:00:44 <tkajinam> o/
16:00:47 <elodilles> o/
16:00:58 <fwiesel> o/
16:01:23 <sean-k-mooney> o/
16:01:31 <bauzas> okay, let's start
16:01:37 <bauzas> shall be quick
16:01:45 <bauzas> #topic Bugs (stuck/critical)
16:01:49 <bauzas> #info No Critical bug
16:01:53 <bauzas> #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster
16:01:55 <bauzas> voilà :)
16:02:00 <auniyal> o/
16:02:08 <bauzas> as said in the PTG, I removed the check on the new bugs number :)
16:02:23 <bauzas> any bug to discuss ?
16:02:29 <elodilles> yepp
16:02:40 <elodilles> https://etherpad.opendev.org/p/nova-bug-triage-20240416
16:02:56 <elodilles> on the top there are 'two possible duplication'
16:03:28 <elodilles> if you agree then i'm marking them as duplicate
16:03:56 <sean-k-mooney> i think so yes
16:04:10 <bauzas> cool with me
16:04:19 <elodilles> ACK, thanks, then i'll do that
16:04:31 <elodilles> that's it i think
16:04:31 <bauzas> ++
16:04:36 <bauzas> moving on, then ?
16:04:42 <elodilles> yepp
16:05:27 <bauzas> cool
16:05:31 <bauzas> #topic Gate status
16:05:35 <bauzas> #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs
16:05:38 <bauzas> #link https://etherpad.opendev.org/p/nova-ci-failures-minimal
16:05:42 <bauzas> #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly Nova&Placement periodic jobs status
16:05:45 <bauzas> #info Please look at the gate failures and file a bug report with the gate-failure tag.
16:05:50 <bauzas> #info Please look at the gate failures and file a bug report with the gate-failure tag.
16:05:54 <bauzas> #info #info Please try to provide meaningful comment when you recheck
16:06:17 <bauzas> any person has found some new gate failure ?
16:07:28 <sean-k-mooney> the only thing i will note is one patches i looked at had a bunch of cancled jobs
16:07:36 <sean-k-mooney> i assume there was a zuul restart over the weekend
16:07:39 <bauzas> looks to me that we have centos9 issue https://zuul.openstack.org/build/8d4e9f1c68f548c899f1575b8b7649fd
16:07:55 <bauzas> for fips
16:08:20 <bauzas> apart of that, all the periodic jobs were okay
16:08:21 <sean-k-mooney> that was just a kernel paninc
16:08:29 <sean-k-mooney> in a volume detach job
16:08:50 <sean-k-mooney> test_resize_volume_backed_server_confirm failed with " ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00001000 ]---"
16:09:24 <sean-k-mooney> all the rest past so i think we can ignore that
16:09:49 <bauzas> yup
16:09:52 <bauzas> moving on then
16:09:58 <bauzas> #topic Release Planning
16:10:03 <bauzas> #link https://releases.openstack.org/dalmatian/schedule.html
16:10:07 <bauzas> #info Dalmatian-1 in 3 weeks
16:10:12 <bauzas> #action bauzas to add the nova deadlines in the Dalmatian schedule page
16:10:37 <bauzas> for the moment, we don't have any review day this month
16:11:08 <bauzas> #topic vPTG Summary
16:11:18 <bauzas> #info The vPTG was held on Apr 8-12
16:11:24 <bauzas> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/P5HFYXU2VPGEJTY26SLBTU3LTAIVMGZT/ Nova PTG summary
16:11:32 <bauzas> in case you haven't seen the email ^
16:11:50 <bauzas> sean-k-mooney: thanks for having replied to it
16:12:00 <bauzas> (to explain more)
16:12:19 <bauzas> nothing I should tell more I think
16:12:24 <bauzas> #topic Review priorities
16:12:29 <bauzas> #link https://etherpad.opendev.org/p/nova-dalmatian-status
16:12:34 <sean-k-mooney> i have a related question for the open discuss section but it was a good summary
16:12:35 <bauzas> I'll update it shortly
16:12:42 <bauzas> sean-k-mooney: shoot
16:12:47 <bauzas> oh
16:12:59 <bauzas> okay, let's do it in the open discussion topic
16:13:10 <bauzas> #topic Stable Branches
16:13:19 <bauzas> elodilles: time is yours
16:13:25 <elodilles> #info no recent merges, but stable/202*.* branches' gates should be OK
16:13:37 <elodilles> #info stable/zed is still blocked by nova-ceph-multistore (constantly failing)
16:13:44 <elodilles> on the other hand:
16:13:50 <elodilles> #info stable/zed is about to move to Unmaintained: https://review.opendev.org/c/openstack/releases/+/916472
16:14:00 <elodilles> for this, the question follows:
16:14:08 <elodilles> do we want to prepare a final stable/zed release? (content would be: https://paste.opendev.org/show/bCISlMJXDFrMjVD5kyaS/ )
16:14:26 <sean-k-mooney> yes
16:14:29 <bauzas> yup
16:14:44 <sean-k-mooney> the two libvirt ones are required for windows guest on arm and live migration of windows guests
16:14:54 <sean-k-mooney> *windows guests on amd hosts not arm
16:15:16 <elodilles> currently we cannot merge more fixes, only if we set ceph-multistore non-voting :/ (or someone has time to investigate the gate issue there)
16:15:28 <sean-k-mooney> well they are merged
16:15:36 <elodilles> ACK for the release, then i'll prepare a release patch for that
16:16:02 <bauzas> ++
16:16:03 <sean-k-mooney> on a related note
16:16:06 <elodilles> sean-k-mooney: i meant for the patches that haven't merged yet o:) there are some waiting
16:16:10 <bauzas> elodilles: ping me when you provide it
16:16:17 <elodilles> bauzas: will do
16:16:27 <bauzas> elodilles: for the moment, I'm a bit off the channel and the gerrit emails
16:16:38 <bauzas> thanks
16:16:50 <sean-k-mooney> ah ok. if there was a impoant patch i would not be agsint makign it non-voting, for 2023.1 shoudl we prepare a patch to remove the grenade job
16:17:25 <sean-k-mooney> my inclination is we shoud remove the grenade jobs form 2023.1 when stable/zed moves to unmaintained/zed
16:17:45 <sean-k-mooney> i lean to do ing that before the branch is renamed but we could do it after
16:18:09 <elodilles> sean-k-mooney: probably that will be needed after stable/zed will be deleted, but might be possible to keep it, we have to check when we get there
16:18:39 <sean-k-mooney> im not sure if we want to keep it
16:18:42 <sean-k-mooney> even if its possible
16:19:08 <sean-k-mooney> since upgrade supprot form unmainiend branches is not impleied and is actully expressly not supproted
16:19:09 <elodilles> if the job is passing then why remove it?
16:19:26 <sean-k-mooney> mainly to save gate resouces by not testing somethign we dont supprot
16:19:30 <elodilles> but yes, let's see first how it will behave :)
16:19:38 <sean-k-mooney> ack
16:19:50 <bauzas> cool
16:19:58 <bauzas> we could discuss this in the gerrit change
16:20:04 <elodilles> +1
16:20:12 <elodilles> last note from me:
16:20:15 <elodilles> #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci
16:20:37 <elodilles> that's all about stable branches
16:21:36 <bauzas> cool
16:21:46 <bauzas> #topic vmwareapi 3rd-party CI efforts Highlights
16:21:51 <bauzas> fwiesel: anything ?
16:21:54 <fwiesel> #info Nothing to report.
16:22:26 <fwiesel> Just a short reminder or request for a second review of my proposed patch: https://review.opendev.org/c/openstack/nova/+/909474
16:22:44 <bauzas> OK, I'll try to look at it
16:23:25 <fwiesel> I understdoot that there was the idea to have a subteam for the vmwareapi driver. Is that the right time to raise that topic?
16:23:33 <sean-k-mooney> its relitivly short and i belive its correct but i agree it would be good to make a decision on that sooner rather then later
16:23:49 <sean-k-mooney> sure
16:24:06 <dansmith> oh yeah I need to look at that
16:25:31 <fwiesel> Thanks, that would be then all from my side.
16:28:13 <bauzas> ++
16:28:27 <bauzas> #topic Open discussion
16:28:32 <bauzas> nothing from me
16:28:37 <bauzas> sean-k-mooney: you had an item
16:28:50 <sean-k-mooney> yes its mainly a question fo paperwork
16:29:12 <bauzas> shoot
16:29:15 <sean-k-mooney> for the eventlet removeal work, ill create a bluepirnt eventlet-removal-part-1
16:29:23 <sean-k-mooney> i assume i shoudl also have a spec?
16:29:53 <sean-k-mooney> or do we want to review the blueprint first and see if we are ok with a specless blueprint
16:30:04 <bauzas> no
16:30:17 <bauzas> we said at the PTG that I'll automatically accept it as specless :)
16:30:41 <bauzas> in case we need to discuss some specific design nits for upgrade concerns, per say, then we could ask later for a spec
16:30:43 <sean-k-mooney> ok then ill work on a bluepirnt for the next meeting to define a semi detialed scope for this cycle
16:31:04 <bauzas> cool
16:31:20 <bauzas> I think we all agreed on the direction so we should be good
16:31:40 <bauzas> maybe the threadpools could have some concerns but we can discuss them in the implementation changes
16:32:00 <sean-k-mooney> ack that was basically all i wanted to confirm
16:32:02 <bauzas> for the workers using direct threads, I don't think we have any problems
16:32:30 <sean-k-mooney> well in generall i would prefer to aovid spawning raw thread outside of a pool in new places
16:32:35 <bauzas> we said we prefered to use parallel threads instead on concurrent ones
16:32:39 <sean-k-mooney> but as you said we can review that on the patches
16:33:08 <bauzas> there are different threads, right?
16:33:40 <sean-k-mooney> you will have to rephase that question, im not following.
16:33:41 <dansmith> what does "parallel instead of concurrent" mean?
16:33:44 <bauzas> like, for the services workers, it's not a problem, we would create all the threads when starting the service
16:34:07 <sean-k-mooney> your repheing to how we have a worker count for the schduler
16:34:20 <bauzas> dansmith: I mean that we would thread instead of greenthreading
16:35:00 <sean-k-mooney> ok yes we woudl be using pthreads/OS threads instead fo userland/green threads
16:35:02 <dansmith> bauzas: okay so you mean async instead of one of parallel or concurrent I think, but okay
16:35:18 <sean-k-mooney> in pything the gil means they are still concurrent not turely parallel
16:35:37 <sean-k-mooney> *in python
16:35:39 <bauzas> sure
16:35:51 <bauzas> we still have the GIL so they're not really paralled
16:35:59 <bauzas> but they're threads
16:36:05 <dansmith> they're still parallel, IMHO
16:36:05 <sean-k-mooney> yes
16:36:07 <fwiesel> Depends on the context... c-extensions may release the lock and run really in parallel
16:36:15 <dansmith> right
16:36:33 <bauzas> anyway, let me reexplain it
16:36:34 <dansmith> they're parallel but with a ton of shared/locked data structures :)
16:36:35 <sean-k-mooney> ya and there are other case wehre the gil is droped too
16:36:36 <fwiesel> Would help with the parsing of the huge xml documents we sometimes get in the vmwareapi
16:36:47 <dansmith> let's just move on, I think we know what we agreed
16:36:54 <sean-k-mooney> sure
16:37:09 <bauzas> we will use 'python threads" instead of "other concurrent/green threading way"
16:37:37 <sean-k-mooney> yes throught the api of a futureist executor in most cases
16:37:41 <bauzas> so, anything else to say?
16:37:53 <sean-k-mooney> nope
16:37:56 <bauzas> cool
16:37:59 <bauzas> thanks all
16:38:12 * bauzas goes back to looking at his devstack issues :(
16:38:16 <bauzas> #endmeeting