16:00:21 <bauzas> #startmeeting nova
16:00:21 <opendevmeet> Meeting started Tue Apr 11 16:00:21 2023 UTC and is due to finish in 60 minutes.  The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:21 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:21 <opendevmeet> The meeting name has been set to 'nova'
16:00:31 <bauzas> heydo heya
16:00:43 <bauzas> #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting
16:00:49 <elodilles> o/
16:02:53 <gibi> o/
16:02:56 <bauzas> hmmmm,
16:03:07 <bauzas> okay, let's start
16:03:11 <gibi> what a crowd
16:03:19 <Uggla> o/
16:03:22 <bauzas> thanks Hungary
16:03:23 <auniyal> o/
16:03:29 <bauzas> hah, people arrive :)
16:03:39 <bauzas> #topic Bugs (stuck/critical)
16:03:44 <bauzas> #info No Critical bug
16:03:48 <bauzas> #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 19 new untriaged bugs (-3 since the last meeting)
16:04:09 <bauzas> unfortunately a new bug just arrived one minute before the meeting started :)
16:04:37 <bauzas> I haven't created an etherpad since most of the bugs I closed were not really needed to be look
16:04:42 <bauzas> looked*
16:04:56 <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:08 <bauzas> gibi: are you able to look at some bug reports this week ?
16:05:18 <bauzas> I can also continue to look at some of them, like the new mdev one :)
16:05:18 <gibi> I can try
16:05:26 * gibi makes a note
16:05:32 <bauzas> gibi: thanks
16:05:36 <bauzas> #info bug baton is being passed to gibi
16:05:48 <bauzas> any bug people want to discuss ?
16:05:58 * gibi has a new post-it on his monitor now
16:06:47 <bauzas> :)
16:06:53 <bauzas> ok, moving on then
16:06:59 <bauzas> #topic Gate status
16:07:03 <bauzas> #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs
16:07:08 <bauzas> #link https://etherpad.opendev.org/p/nova-ci-failures
16:07:20 <bauzas> it was a short week for me, so I haven't seen any CI issue
16:07:28 <dansmith> it's not great
16:07:44 <bauzas> I've seen some gate issues last week indeed
16:07:53 <dansmith> I'm not sure how much of it is nova's fault, other than the functional failures
16:08:17 <bauzas> yeah :(
16:08:35 <bauzas> again, I'll try to look at those this week
16:08:38 <dansmith> I don't have any specific things to raise, but I can just say it's not great at the moment
16:08:44 <bauzas> and maybe ping some folks
16:09:07 <bauzas> dansmith: cool, anyway thanks for having it looked
16:09:26 <bauzas> #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly Nova&Placement periodic jobs status
16:09:45 <bauzas> at least for periodic jobs, all of them work :) ^
16:09:56 <bauzas> #info Please look at the gate failures and file a bug report with the gate-failure tag.
16:10:00 <bauzas> #info STOP DOING BLIND RECHECKS aka. 'recheck' https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures
16:10:07 <bauzas> moving on then
16:10:13 <bauzas> #topic Release Planning
16:10:18 <bauzas> #link https://releases.openstack.org/bobcat/schedule.html
16:10:23 <bauzas> #link https://review.opendev.org/c/openstack/releases/+/877094 Proposed deadlines for Bobcat
16:10:38 <bauzas> elodilles: thanks for having reviewed it, I don't know what happened with my agenda :)
16:10:53 <elodilles> sure, np :]
16:11:24 <bauzas> elodilles: I'll verify the days again
16:11:34 <bauzas> and I'll rebase it after this meeting
16:12:28 <bauzas> #info Bobcat-1 is in 4 weeks
16:12:34 <bauzas> #topic Review priorities
16:12:38 <bauzas> #link https://review.opendev.org/q/status:open+(project:openstack/nova+OR+project:openstack/placement+OR+project:openstack/os-traits+OR+project:openstack/os-resource-classes+OR+project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/osc-placement)+(label:Review-Priority%252B1+OR+label:Review-Priority%252B2)
16:12:42 <bauzas> #info As a reminder, cores eager to review changes can +1 to indicate their interest, +2 for committing to the review
16:12:47 <bauzas> #topic Stable Branches
16:13:05 <bauzas> elodilles: your time (and then auniyal's ;) )
16:13:40 <elodilles> #link https://review.opendev.org/c/openstack/releases/+/878860 Xena stable branche EM proposal
16:13:47 <elodilles> #info final Xena release tracking pad: https://etherpad.opendev.org/p/nova-stable-xena-em
16:14:01 <elodilles> just some summary based on this ^^^
16:14:09 <elodilles> we have merged some patches
16:14:39 <elodilles> but there are still patches that can be reviewed
16:14:43 <bauzas> yup
16:15:10 <elodilles> the question is, whether we should not wait anymore and do a final release for stable/xena
16:15:13 <bauzas> elodilles: honestly I don't know what to review
16:15:28 <bauzas> I've asked if other folks wanted to merge stuff
16:15:35 <bauzas> the ones I cared I dared to review
16:15:44 <elodilles> bauzas: i also haven't find any 'must-have' for stable/xena final release
16:16:02 <bauzas> gibi: maybe you want some of your xena backported series to be merged before we call out EM ?
16:16:07 <elodilles> maybe we are ready to do the final release then?
16:16:22 <gibi> bauzas: I have nothing super pressing
16:16:36 <bauzas> well,
16:16:40 <gibi> but if we can merge open patches that sounds good :)
16:16:45 <elodilles> #info note that we can merge patches AFTER the transition, just cannot do upstream releases anymore
16:16:52 <gibi> understood ^^
16:17:07 <bauzas> yeah, this isn't a priority question
16:17:27 <bauzas> if people want to release their backports, they NEED to beg for reviews by now
16:17:45 <elodilles> ++
16:17:51 <bauzas> we could merge patches after EM, but then none of the patches would get released
16:18:10 <bauzas> if people are happy with cherry-picking, this isn't a problem
16:18:25 <bauzas> but if people rely on pip packages, they may get surprised
16:18:26 <sean-k-mooney> well we will merge patches after EM
16:18:39 <sean-k-mooney> but yes it wont get included in an upstream release
16:18:41 <bauzas> I just wrote that :)
16:18:56 <sean-k-mooney> well you said could impliying we might not
16:18:58 <bauzas> anyway, looks to me none of us are telling nay
16:19:04 <elodilles> but downstream it can be consumed & released ;)
16:19:10 <sean-k-mooney> exactly
16:19:20 <bauzas> elodilles: IMHO you're good to go
16:19:22 <sean-k-mooney> so we still want to continue to merge them after EM
16:19:32 <bauzas> elodilles: propose the releases patch and auniyal and I will +1 it
16:20:08 <elodilles> bauzas: ack
16:20:21 <bauzas> auniyal: you had a subitem
16:20:29 <bauzas> about yoga and zed branches
16:20:32 <auniyal> yes bauzas
16:20:36 <auniyal> #info Please review these backport patches for stable zed and yoga release
16:20:51 <auniyal> #link https://etherpad.opendev.org/p/release-liaison-PatchesToReview
16:20:59 <auniyal> thats all :)
16:22:19 <bauzas> ok thanks auniyal
16:22:50 <bauzas> stable cores are welcome to review https://etherpad.opendev.org/p/release-liaison-PatchesToReview
16:23:10 <bauzas> auniyal: when do you plan to propose a stable release for yoga and zed ?
16:23:27 <auniyal> 20 April
16:24:00 <bauzas> ack
16:24:11 <sean-k-mooney> can you take a look at all nova deliverable fi you are doing that
16:24:12 <bauzas> let's revisit then on next weekly meeting
16:24:22 <sean-k-mooney> so os-vif, placement ectra
16:24:25 <sean-k-mooney> not just nova
16:24:40 <sean-k-mooney> i dont think we have a lot pending for those
16:25:06 <bauzas> sean-k-mooney: you mean the stable branches ?
16:25:12 <bauzas> yeah, that doesn't harm
16:25:15 <auniyal> ack sean-k-mooney, I am making same list for os-vif, placement and os-trait
16:25:28 <bauzas> auniyal: just use the same tracking etherpad IMHO
16:25:41 <auniyal> but I share them once I review them
16:25:44 <auniyal> ack bauzas
16:25:45 <bauzas> cool thanks
16:25:45 <sean-k-mooney> cool
16:25:55 <bauzas> ok, I guess we're done with this topic
16:26:05 <sean-k-mooney> for what its worth i dont see anythign for os-vif
16:26:11 <bauzas> thanks elodilles and auniyal for taking care of our eldests
16:26:18 <elodilles> ++
16:26:26 <bauzas> moving on
16:26:47 <bauzas> actually,
16:26:54 <bauzas> #topic Open discussion
16:27:01 <bauzas> there is nothing in the etherpad
16:27:06 <sean-k-mooney> refrsh
16:27:06 <bauzas> s/etherpad/wige
16:27:12 <sean-k-mooney> i added a topic
16:27:27 <bauzas> heh, I'm used to refresh but I forgot this time
16:27:32 <bauzas> (sean-k-mooney) hypervisor version weighed.
16:27:36 <bauzas> go for it then :)
16:27:46 <sean-k-mooney> so this is pretty simple
16:27:57 <sean-k-mooney> i would like to add a new scheduler weigher
16:28:20 <sean-k-mooney> that woudl weigh hosts based on the Hypervisror_version filed in the hoststate object
16:28:29 <sean-k-mooney> and prefer putting vms on new hosts
16:28:42 <sean-k-mooney> this will help with upgrades both pratically and with testing
16:28:50 <dansmith> yeah, I'm not sure who would argue against such behavior, so it sounds like a good idea to me
16:28:56 <bauzas> me too
16:29:03 <bauzas> and it's a weigher
16:29:06 <bauzas> not a filter
16:29:07 <sean-k-mooney> what i would like to know is shoudl this be a specless bluepint or mini spec liek the pci weigher
16:29:08 <dansmith> every cloud I've worked with has wanted to move instances towards newer hosts
16:29:31 <bauzas> sean-k-mooney: do you need to add new fields for the ComputeNode records ?
16:29:37 <sean-k-mooney> no
16:29:38 <gibi> does hypervisror_version field something that is always meaningfully comparable?
16:29:41 <bauzas> I think no
16:29:43 <sean-k-mooney> no db or object chanbges
16:29:53 <sean-k-mooney> gibi: that is a good question
16:29:59 * bauzas very quickly looks at the existing host states
16:30:03 <sean-k-mooney> so initally i was just going to do this for libvirt/qemu
16:30:21 <sean-k-mooney> for the libvirt driver its the libvirt verison
16:30:28 <sean-k-mooney> converted to a number
16:30:35 <sean-k-mooney> so 7.0.0 becomes 700000000
16:30:44 <dansmith> it's an integer, so it's certainly easily comparable
16:30:46 <sean-k-mooney> i dont know if all virt driver are comparibale
16:30:47 <bauzas> https://github.com/openstack/nova/blob/master/nova/scheduler/host_manager.py#L129
16:30:57 <bauzas> at least we have this field
16:30:59 <dansmith> if someone is not putting something where "bigger means newer" in an integer field, it would be very strange
16:31:13 <sean-k-mooney> is it an int in the db
16:31:18 <dansmith> it is
16:31:29 * bauzas wonders why we already provide this id
16:31:32 <gibi> then it is OK
16:31:36 <sean-k-mooney> ok then i think it will work for eventying
16:31:39 <bauzas> s/id/field
16:31:47 <sean-k-mooney> the weigher just need to return the value as the weight directly
16:32:08 <sean-k-mooney> and it will be nomalised/multipled like all the rest
16:32:21 <bauzas> well, then if all the drivers provide this field, and if the HostState already has this, then there is no upgrade question
16:32:29 <bauzas> so,
16:32:29 <bauzas> specless blueprint to me
16:32:47 <bauzas> oh heh, we already query it https://github.com/openstack/nova/blob/50fdbc752a9ca9c31488140ef2997ed59d861a41/nova/scheduler/filters/image_props_filter.py#L85
16:32:50 <dansmith> seems okay to me if there are no other wrinkles
16:33:04 <gibi> OK to me too
16:33:08 <bauzas> so, basically, we already support this field
16:33:14 <sean-k-mooney> bauzas: we do yes
16:33:16 <bauzas> definitely a specless bp
16:33:18 <sean-k-mooney> and we use it in the conductor
16:33:27 <sean-k-mooney> to prevent live migrating form new to older
16:33:28 <bauzas> sean-k-mooney: my question was more about the scheduler
16:33:34 <sean-k-mooney> yep
16:33:40 <sean-k-mooney> ok ill file the blueprint after the meeting
16:33:42 <bauzas> I was wondering why we were having a HostState field
16:33:48 <sean-k-mooney> and ill detail this in the describption
16:33:57 <bauzas> that was meaning that we were already a filter using it
16:33:59 <sean-k-mooney> yep i check that already
16:34:01 <sean-k-mooney> we do
16:34:05 <bauzas> cool cool
16:34:07 <bauzas> so,
16:34:40 <sean-k-mooney> i will file a blueprint and i will ping you the link once done for you to review
16:35:03 <bauzas> #agreed a blueprint asking to have a weigher using hypervisor_version would be a specless one
16:35:25 <bauzas> #action sean-k-mooney to ping bauzas once he creates it
16:35:28 <bauzas> voila
16:35:41 <bauzas> anything else ?
16:36:06 <bauzas> if not
16:36:10 <bauzas> thanks all,
16:36:13 <bauzas> #endmeeting