16:00:57 <bauzas> #startmeeting nova
16:00:57 <opendevmeet> Meeting started Tue Oct 29 16:00:57 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:57 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:57 <opendevmeet> The meeting name has been set to 'nova'
16:00:59 <bauzas> what's up folks !
16:01:11 <bauzas> #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting
16:01:14 <bauzas> who's around ?
16:01:14 <tkajinam> o/
16:01:15 <dansmith> o/
16:01:59 <bauzas> let's try to have a very short but productive meeting, since we had the PTG last week
16:02:45 <bauzas> #topic Bugs (stuck/critical)
16:02:54 <bauzas> #info No Critical bug
16:03:01 <bauzas> #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster
16:03:16 <bauzas> any important bug you'd like to raise ?
16:03:21 * gibi finishing a meeting
16:03:55 <bauzas> okay moving on so
16:04:02 <bauzas> #topic Gate status
16:04:09 <bauzas> #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs
16:04:14 <bauzas> #link https://etherpad.opendev.org/p/nova-ci-failures-minimal
16:04:21 <bauzas> #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly Nova&Placement periodic jobs status
16:04:28 <bauzas> #info Please look at the gate failures and file a bug report with the gate-failure tag.
16:04:38 <bauzas> #info Please try to provide meaningful comment when you recheck
16:04:57 <bauzas> I looked at some changes this week, but I haven't seen any problem so far
16:05:09 <bauzas> anything people saw on our gate ?
16:05:52 <Uggla> o/
16:06:01 <sean-k-mooney> o/
16:06:14 <tkajinam> nothing I'm aware of
16:06:28 <fwiesel> o/
16:06:29 <bauzas> before moving on, I'm still awaiting the results of the periodic checks
16:06:35 <bauzas> gosh, it takes a while
16:07:04 <tkajinam> py38 was removed from master u-c so now py38 job may be completely broken in master, but we believe we already bumped the min version of all nova deliverables so no job may still run in py38 for master
16:07:13 <bauzas> ah, got it, all periodics in green except nova-emulation on 2023.2 stable branch
16:07:18 <tkajinam> https://review.opendev.org/c/openstack/requirements/+/925201
16:07:20 <tkajinam> just fyi
16:07:48 <tkajinam> next big event may be switch to noble, I expect
16:07:55 <bauzas> tkajinam: thanks for the note, I'll mention something about that in the next topic
16:08:11 <bauzas> tkajinam: when is planned that big change ?
16:08:45 <tkajinam> I saw gmann started submitting a few patches for it but I've seen a few projects have problems when run in noble so it may take some time
16:08:47 <sean-k-mooney> it should happen in the next few weeks
16:09:05 <sean-k-mooney> so ideally before m1 perhaps m2 at the very latest
16:09:12 <tkajinam> yeah
16:09:32 <sean-k-mooney> nova-next has been on it since last cycle
16:09:40 <tkajinam> https://review.opendev.org/c/openstack/nova/+/932648
16:09:41 <sean-k-mooney> i breifly looked at the docs failure
16:09:47 <sean-k-mooney> nova is in a pretty good state
16:10:00 <tkajinam> probably https://review.opendev.org/q/topic:%22migrate-to-noble%22 is a better link
16:10:05 <sean-k-mooney> i think we just need to add the right dep for pcr2 to bindep
16:10:13 <bauzas> yeah I'm not afraid of the noble change in the gate, but I'd like somehow to get noticed when it happens
16:10:30 <sean-k-mooney> well its for us to review
16:10:42 <sean-k-mooney> there are two parts
16:10:49 <sean-k-mooney> one is devstack will change its default nodeset
16:10:57 <sean-k-mooney> the other is we need to update our in repo jobs https://review.opendev.org/c/openstack/nova/+/932648
16:11:00 <sean-k-mooney> does the latter
16:11:46 <frickler> there's an ML thread on the noble upgrade https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/JOMDY26TCW7OX3NXRGOYQCIDXNNJ4E25/
16:11:51 <bauzas> ok, I'll cc myself on gmann's patch
16:11:56 <frickler> I assume gmann will update once ready
16:12:35 <sean-k-mooney> yep so at the momp[ent the only blocker on teh nova side that im aware of is including the correct package for prce.h
16:12:42 <sean-k-mooney> in the docs jobs (api ref ectra)
16:12:58 <frickler> ack, lots of other projects look much worse off
16:13:04 <bauzas> hence the failure
16:13:18 <sean-k-mooney> yep so in my devstack i have pcre 2 and 3 and maybe 1 installed
16:13:32 <sean-k-mooney> we just need to see which one actully provides the correct dep
16:13:35 <bauzas> ack
16:13:41 <sean-k-mooney> the packaging of that is a bit weired and may have changed
16:13:49 <bauzas> I guess we're cool then
16:13:58 <sean-k-mooney> more or less
16:14:02 <opendevreview> Merged openstack/nova master: Refactor obj_make_compatible to reduce complexity  https://review.opendev.org/c/openstack/nova/+/928590
16:14:10 <sean-k-mooney> i think we can just review this as normal
16:14:17 <sean-k-mooney> and check in each week until merged
16:15:05 <bauzas> ok, moving on then
16:15:57 <bauzas> #topic Release Planning
16:16:03 <bauzas> #link https://releases.openstack.org/epoxy/schedule.html
16:16:09 <bauzas> #action bauzas to add Epoxy nova deadlines in the schedule
16:16:41 <bauzas> if you were not present at the PTG, you need to know that we'll have a spec soft freeze by mid-Dec
16:16:54 <bauzas> plan in advance to write your spec accordingly
16:17:10 <bauzas> the earlier the better as always
16:17:24 <bauzas> #topic Review priorities
16:17:30 <bauzas> #link https://etherpad.opendev.org/p/nova-2025.1-status
16:17:55 <bauzas> I moved some stuff, but I need to do a scan check of all the items in there
16:18:19 <bauzas> #topic PTG summary
16:18:27 <bauzas> for those who were not able to attend :
16:18:36 <bauzas> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/HZZPADKTWNMBGRSOEMSPLN432DXZYYTL/
16:18:52 <bauzas> feel free to raise questions or remarks in that thread
16:19:05 <bauzas> #topic Stable Branches
16:19:18 <bauzas> hah, elodilles_pto is on PTO as the nick says
16:19:40 <bauzas> let's move on then to the next topic unless someone wants to raise something about stable branches
16:19:45 <zigo> FYI (about this link): We'd love to have "vTPM live migration" implemented... :P
16:20:01 <bauzas> zigo: make a wish
16:20:31 <sean-k-mooney> many woudl and there is at least some hope that it will be doen in epoxy
16:20:57 <sean-k-mooney> its non trivial however without wekening security
16:20:58 <bauzas> there is already some code there so the wish wouldn't be too hard to do
16:21:49 <sean-k-mooney> yes and no the current code is not accpabel as is as it wont work in the general case without custom policy
16:21:52 <bauzas> zigo: if you really like the case, please review the spec then once it's uploaded
16:22:05 <sean-k-mooney> but that is why we are goign to have a spec and try and delvier a better generic solution
16:22:40 <bauzas> zigo: as sean-k-mooney is explaining, we discussed about user bond of trust with admins
16:22:57 <bauzas> so I'd like your op voice to be shared on that spec
16:23:49 <bauzas> anyway, let's not derail the meeting into a technical discussion about a specific feature
16:24:20 <bauzas> moving on (and I think we can skip the stable branches topic for today)
16:24:23 <bauzas> #topic vmwareapi 3rd-party CI efforts Highlights
16:24:33 <bauzas> fwiesel: want to share something ?
16:27:47 <fwiesel> Yes, sorry. I found a regression in our networking driver and fixed it. But there is another one.
16:28:26 <fwiesel> Some race-condition in the startup. I am optimistic that I can fix it this week.
16:28:46 <fwiesel> That's from my side. Back to you bauzas.
16:29:03 <bauzas> thanks
16:29:10 <bauzas> and good luck with the investigation
16:29:19 <bauzas> #topic Open discussion
16:29:48 <bauzas> just refreshed the page, nothing in there
16:29:53 <bauzas> so, anything anyone ?
16:30:37 <tkajinam> I've proposed oslo.utils release so we hopefully get it soon and can use it for some work in nova https://review.opendev.org/c/openstack/releases/+/933627
16:30:38 <sean-k-mooney> i tought there was somethign we said to cover in the meeting instead of the ptg
16:30:40 <sean-k-mooney> but i dont recall
16:30:43 <tkajinam> dansmith, ^^^ just fyi
16:30:47 <dansmith> tkajinam: thanks
16:30:52 <bauzas> tkajinam: thanks
16:31:05 <tkajinam> I'll work on https://bugs.launchpad.net/nova/+bug/2083518 once the release is created
16:31:52 <sean-k-mooney> i might be thinkign of https://review.opendev.org/c/openstack/nova-specs/+/932653 but i highlighted that in the cidner cross project
16:32:21 <tkajinam> sean-k-mooney, ah, yeah
16:32:23 <bauzas> yeah, we had no topics that were left to be discussed
16:32:26 <sean-k-mooney> tkajinam: you are porting that to oslo yes
16:32:40 <sean-k-mooney> and we will just consume the predecate form there once its released
16:32:49 <tkajinam> sean-k-mooney, yes. you are correct.
16:33:09 <sean-k-mooney> ya so i dont see anythign contoversion with that so im happy to review that when its ready
16:33:22 <tkajinam> :-)
16:34:13 <tkajinam> sean-k-mooney, talking about the spec you raised... I think you spotted a nice point and we need a new mechanism in cinder (qos specs which are not used by cinder but by nova during attachment)
16:34:43 <tkajinam> I overlooked the fact that the prpoosal is trying to use the existing qos specs but these are cinder internal one and can't be used by nova
16:34:47 <sean-k-mooney> well frontend qos policies are use by the hypervior (libvirt in this case)
16:35:03 <sean-k-mooney> to enforce it where as backend qos polcies are done on the stroage backend
16:35:04 <tkajinam> but that qos is associated with flavor, right ?
16:35:09 <sean-k-mooney> no
16:35:16 <sean-k-mooney> its assocated witht eh volume
16:35:30 <sean-k-mooney> we also have the ablity to do it via the flavor for nova created block devices
16:35:38 <sean-k-mooney> using the quota:* extra specs
16:36:12 <sean-k-mooney> i belive the current state is you can configure hard limits today
16:36:15 <sean-k-mooney> but not burst
16:36:27 <sean-k-mooney> and the brust limist are what they want to enabel
16:36:34 <sean-k-mooney> but that was my question to the cinder folk
16:36:50 <tkajinam> ok
16:36:51 <sean-k-mooney> to have them confirm what is and is not expected to be requestable vai cinder today
16:36:57 <tkajinam> I thought the qos specs are not propagated via connection info but it's set in storage backend
16:37:08 <tkajinam> I'll recheck it and fix my comments in that spec if needed
16:37:28 <sean-k-mooney> you set them on the voluem type and im not sure how they are propegated to nova
16:37:37 <sean-k-mooney> so this is where we need input form the cider folk
16:38:00 <sean-k-mooney> i.e are tehy on teh attachmetn? conection info? do we need to look them up ectra
16:38:05 <bauzas> can we end the meeting ?
16:38:12 <sean-k-mooney> yep i think so
16:38:15 <tkajinam> yeah we can discuss details in the spec
16:38:17 <sean-k-mooney> this can be an async dicussion
16:38:41 <bauzas> cool
16:38:46 <bauzas> then thanks all
16:38:49 <bauzas> #endmeeting