16:01:40 <bauzas> #startmeeting nova
16:01:40 <opendevmeet> Meeting started Tue Sep 10 16:01:40 2024 UTC and is due to finish in 60 minutes.  The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:40 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:40 <opendevmeet> The meeting name has been set to 'nova'
16:01:58 <fwiesel> o/
16:02:07 <elodilles> o/
16:02:10 <dansmith> o/
16:02:11 <sean-k-mooney> o/
16:02:12 <gmann> o/
16:02:17 <bauzas> hey everyone
16:02:20 <bauzas> nice to see you
16:02:24 <sean-k-mooney> welcome back
16:02:35 <bauzas> sorry, was away last week for the OIF Summit Asia
16:02:36 <tkajinam> o/
16:03:26 <auniyal> o/
16:03:28 <bauzas> #topic Bugs (stuck/critical)
16:03:50 <bauzas> #info No Critical bug
16:03:58 <bauzas> #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster
16:04:14 <bauzas> any bug report people would want to discuss ?
16:04:48 <dansmith> maybe one
16:04:58 <dansmith> I filed the bug against oslo and nova,
16:05:11 <bauzas> shoot
16:05:15 <dansmith> but sean-k-mooney, are you still working on excluding the safety check for the ephemeral disks?
16:05:16 <sean-k-mooney> https://bugs.launchpad.net/nova/+bug/2079850
16:05:41 <sean-k-mooney> i have a draft of that locally the unit test are failing so im tryign to fix that
16:05:52 <dansmith> the oslo fix is +2 but it'll take a release and u-c bump before we get it
16:05:54 <dansmith> sean-k-mooney: okay cool
16:06:16 <bauzas> ergh
16:06:42 <bauzas> yet another reason to work on the image backend refactoring if you want MHO
16:06:45 <dansmith> bauzas: basically, if you have nova format your ephemerals as vfat for you, you'll hit this fail
16:07:00 <dansmith> yes, it's really stupid that we're even doing this, and it's at least partially because of the design of the imagebackend
16:07:16 <opendevreview> sean mooney proposed openstack/nova master: [WIP] Add functional repoducer for ephemeral disks  https://review.opendev.org/c/openstack/nova/+/928310
16:07:17 <opendevreview> sean mooney proposed openstack/nova master: [WIP] adapt to vfat support in oslo.utils  https://review.opendev.org/c/openstack/nova/+/928462
16:07:17 <opendevreview> sean mooney proposed openstack/nova master: only saftey check bootable files created form glance  https://review.opendev.org/c/openstack/nova/+/928829
16:07:25 <sean-k-mooney> thats what im working on ^
16:07:30 <dansmith> sean-k-mooney: cool thanks
16:07:34 <bauzas> formatting ephemerals to vfat is like "I don't care about my fs, dude"
16:07:45 <sean-k-mooney> still failing unit test but i should get those passing today
16:07:55 <dansmith> bauzas: right, it's pointless for us to even do that anyway, because nobody would actually use them as fat anyway
16:08:05 <dansmith> bauzas: double pointless behavior :)
16:08:13 <bauzas> I assume this would be for additional disks ?
16:08:18 <dansmith> ephemerals
16:08:30 <sean-k-mooney> i propoaded not formatign ephemeral disk by default before
16:08:42 <sean-k-mooney> we have a blueprint for that that i think we shoudl do in epoxy
16:08:47 <dansmith> yeah, sean-k-mooney I'm on board with that too
16:09:21 <bauzas> ring me a bell, I know what ephemeral disks are in nova, but I wonder *why* people would want vfat
16:09:21 <sean-k-mooney> but for right now just skipign the safty check if the disk is not bootable and thats only set when we chreat ephermal/swap disks in my patch above
16:09:42 <sean-k-mooney> bauzas: its our default when you dont set a config option or image property
16:09:45 <bauzas> probably because they think "ephemeral" means the disks are not persisted (which is not the case)
16:09:56 <sean-k-mooney> we choose it as the only format that would work for every os
16:10:23 <sean-k-mooney> not it was just because we needed something that works on linux and windows
16:10:32 <dansmith> vfat would only be for windows guests so they see something on the disk instead of blank
16:10:33 <sean-k-mooney> if you set os_type in teh image we use ntfs or ext4
16:10:37 <dansmith> but makes no actual sense
16:10:52 <dansmith> sean-k-mooney: we actually support ntfs?
16:10:54 <sean-k-mooney> or if you set the config option we use what you set as the fallback
16:11:01 <sean-k-mooney> yep
16:11:11 <dansmith> either way, we're not partitioning the disk properly anyway.. I guess I'm surprised windows is happy with a whole-disk ntfs
16:11:11 <sean-k-mooney> im not saying you should use it
16:11:15 <sean-k-mooney> but the code is there
16:11:33 <sean-k-mooney> https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.default_ephemeral_format
16:11:34 <dansmith> yeah, I would never use linux-created ntfs for production if I was a windows user
16:12:06 <sean-k-mooney> well cloud model. as a end user you should not know if its hyperv or libvirt/qemu
16:12:30 <bauzas> but you know the image you use
16:12:34 <sean-k-mooney> its in the default section because this applies to other drivers
16:12:51 <dansmith> I mean as the operator I would never configure that,
16:13:03 <dansmith> but you're right, users may not realize they are getting ntfs created by linux that they shouldn't trust :)
16:13:31 <bauzas> agreed on not configure it if I was admin, I'd just assume nova would create me ephemerals that my instance can read
16:13:32 <sean-k-mooney> anyway we can carry this discussion forward to the reveiws
16:13:36 <dansmith> yeah
16:13:42 <sean-k-mooney> but next cycle we can add unformated and set that as the default
16:13:59 <sean-k-mooney> https://blueprints.launchpad.net/nova/+spec/default-ephemeral-format-unformated
16:14:01 <dansmith> with docs and renos suggesting to leave it that way
16:14:21 <sean-k-mooney> we can flag the option with advnaced if we like
16:14:52 <sean-k-mooney> https://docs.openstack.org/oslo.config/latest/reference/defining.html#advanced-option
16:15:39 <sean-k-mooney> anyway we can likely move on
16:15:42 <dansmith> yup
16:15:46 <bauzas> okay
16:15:58 <bauzas> action items are on reviewing the oslo.utils patch, right?
16:16:08 <dansmith> no,
16:16:21 <dansmith> that's on the oslo people and tkajinam has already +2d and asked the other cores to hit it
16:16:35 <dansmith> but again, it won't solve our problem until release/bump
16:16:53 <dansmith> the action item on us should be getting sean's actual fix working,reviewed,merged
16:16:55 <dansmith> (IMHO)
16:17:16 <sean-k-mooney> i have a patch at the end for compatiblity with the oslo change too
16:17:17 <bauzas> are we talking of https://review.opendev.org/q/topic:%22ephmeral-and-swap-backing-files%22 ?
16:17:50 <sean-k-mooney> the first 2 patches yes but ill change the topic of that to the bug topic later
16:17:58 <bauzas> cool
16:18:12 <bauzas> I guess then we can move on
16:18:22 <tkajinam> I can push the oslo.utils to gate if it doesn't get attention from the other cores and hard blocks nova release but note that we may need a few more steps (backport to 2024.1, new release in 2024.1 and req bump)
16:18:30 <bauzas> but do we feel this as a regression bug ?
16:18:32 <tkajinam> which might mean that RC1 release of nova might be delayed because of it
16:18:46 <bauzas> heh, jinxed by tkajinam
16:18:53 <tkajinam> s/2024.1/2024.2/g
16:19:01 <tkajinam> :-)
16:19:04 <sean-k-mooney> tkajinam: its not a hard block really but it is a regression that might require an rc2
16:19:11 <tkajinam> ok
16:19:12 <dansmith> it's not an oslo regression
16:19:20 <bauzas> it's a nova regression
16:19:26 <sean-k-mooney> yep
16:19:28 <dansmith> it is a nova one, but again, it feels like we need to fix our own code anyway
16:19:32 <bauzas> so we need to merge sean's patches before RC1
16:19:47 <sean-k-mooney> ideally but i need to get it passing first
16:19:48 <tkajinam> ok
16:19:51 <bauzas> or deliver RC1 and adress them in RC2
16:20:16 <dansmith> so we could aim to get sean's stuff in to fix,
16:20:22 <bauzas> sean-k-mooney: fwiw, I'm just adding to that bug report the  dalmatian-rc-potential taag
16:20:27 <dansmith> but if we can't for some reason, just getting nova to use the updated oslo will paper over the problem
16:20:42 <tkajinam> makes sense
16:20:45 <bauzas> and I'm flagging that bug in the rc etherpad I'm just gonna speak about in a few
16:20:48 <sean-k-mooney> cool. im going to monitor the meetign but im goign to go back to working on this in parallel
16:21:21 <bauzas> sean-k-mooney: don't freak out, we didn't had RC2s for a while, but I feel brave enough to ship one this time :)
16:22:58 <dansmith> let's move on for real now
16:23:41 <bauzas> okay, did the paperwork
16:23:51 <bauzas> (sorry, took more time than estimate)
16:24:00 <bauzas> #topic Gate status
16:24:06 <bauzas> #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs
16:24:12 <bauzas> #link https://etherpad.opendev.org/p/nova-ci-failures-minimal
16:24:18 <bauzas> #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly Nova&Placement periodic jobs status
16:24:29 <bauzas> nothing to relate except nova-emulation zed again
16:24:47 <bauzas> my bad, nova-emulation on antelope
16:25:09 <bauzas> but since master job run worked like a charm, let's not look at it
16:25:17 <bauzas> #info Please look at the gate failures and file a bug report with the gate-failure tag.
16:25:22 <bauzas> #info Please try to provide meaningful comment when you recheck
16:25:34 <bauzas> anything else about gate stability ?
16:26:25 <bauzas> looks not
16:26:33 <bauzas> #topic Release Planning
16:26:40 <bauzas> #link https://releases.openstack.org/dalmatian/schedule.html
16:26:41 <opendevreview> Merged openstack/os-vif stable/2024.2: Update .gitreview for stable/2024.2  https://review.opendev.org/c/openstack/os-vif/+/928353
16:26:46 <bauzas> #info Dalmatian RC1 planned this week
16:27:14 <bauzas> so, again, I'd appreciate if people chime in if they find regressions
16:27:22 <elodilles> ( there is the generated patch: https://review.opendev.org/c/openstack/releases/+/928551 )
16:27:29 <elodilles> ( rc1 patch for nova)
16:27:43 <bauzas> we now have an etherpad for RC tracking
16:27:46 <bauzas> #link https://etherpad.opendev.org/p/nova-dalmatian-rc-potential
16:28:02 <bauzas> elodilles: thanks, just adding your nova rc1 patch to the etherpad :)
16:28:14 <elodilles> ++
16:29:18 <bauzas> also,
16:29:43 <bauzas> maybe people forgot here that as soon as we branch master with RC1, then master becomes Epoxy :)
16:29:50 <bauzas> accordingly
16:30:04 <bauzas> #info Epoxy development phase will start as soon as we branch RC1
16:30:21 <bauzas> #link https://releases.openstack.org/epoxy/schedule.html
16:30:44 <bauzas> and accordingly, we'll use another etherpad for tracking all the work we'll be doing for Epoxy :
16:30:54 <bauzas> #link https://etherpad.opendev.org/p/nova-2025.1-status
16:31:23 <bauzas> feel free to add any blueprints you would want us to look at or any bug report you'd want to fix by Epoxy timeframe
16:32:04 <bauzas> based on my discussions at the OIF Summit Asia, I was also convinced to update our docs to mention our tracking system
16:32:25 <bauzas> #action bauzas to update the contributor docs to mention the etherpad and how to reach the nova community
16:33:11 <bauzas> that's it for me for release planning
16:33:20 <bauzas> anything else to add ?
16:33:30 <bauzas> oh
16:33:35 <bauzas> I forgot
16:33:53 <bauzas> in the rc tracking etherpad, I have a couple of patches I'd beg cores to review
16:34:12 <gibi> I went through that list so we need one more cores
16:34:20 <bauzas> particularly the highlights
16:34:23 <gibi> s/cores/core/
16:34:27 <bauzas> gibi: thanks !
16:34:57 <gmann> I +w few of them
16:35:13 <bauzas> gmann: thanks too
16:35:26 <bauzas> okay, I'll chase the patches and bug people eventually
16:35:29 <bauzas> moving on then
16:35:38 <bauzas> #topic Review priorities
16:35:59 <bauzas> this is currently punted to once we branch RC1
16:36:35 <bauzas> the current priorities are now clearly bugfixes, particularly if they are regression ones :)
16:36:47 <bauzas> #topic Stable Branches
16:36:55 <bauzas> elodilles: take the baton
16:36:59 <elodilles> o7
16:37:02 <elodilles> #info stable/202*.* gates seem to be OK
16:37:16 <elodilles> #info stable/2024.2 branch were cut for libraries
16:37:44 <elodilles> #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci
16:38:19 <elodilles> please add gate errors in the pad if anyone finds one ^^^
16:38:35 <elodilles> and that's all about stable branches from me
16:39:14 <bauzas> all good
16:39:34 <bauzas> #topic vmwareapi 3rd-party CI efforts Highlights
16:39:37 <fwiesel> #info No updates.
16:39:38 <bauzas> fwiesel: your time
16:39:42 <bauzas> cool with me
16:39:53 <bauzas> #topic Open discussion
16:40:14 <bauzas> we have one time that was carried over from last week, I'd say
16:40:16 <bauzas> (whoami-rajat) Add multipath_id to the BDM in case of iSCSI
16:40:25 <bauzas> whoami-rajat: are you available now ?
16:41:21 <sean-k-mooney> gibi and i have looked at the patch
16:41:40 <sean-k-mooney> effectivly they want to do this to make debuging with db dubps simplere
16:41:58 <sean-k-mooney> apprently only nova and the network backend has the multipath_id
16:42:10 <bauzas> orly?
16:42:25 <sean-k-mooney> and this is useful for them to be able to corralate the instance and the volume on the storage backend
16:42:51 <sean-k-mooney> im a little reluctant to add the multipath id just for debuging but not 100% agisnt it
16:43:01 <sean-k-mooney> i left a comment to that effect on the patch
16:43:18 <bauzas> and I guess the BDM is a blob ?
16:43:37 <bauzas> no database update needs ?
16:44:02 <sean-k-mooney> https://review.opendev.org/c/openstack/nova/+/889257
16:44:15 <sean-k-mooney> its a json blob i belive yes
16:44:46 <bauzas> I don't get why we need to persist it
16:44:55 <bauzas> couldn't we show it in the logs ?
16:45:00 <gibi> It feels wrong that nova perists a data that nova never uses and never passes along
16:45:30 <sean-k-mooney> hum https://github.com/openstack/nova/blob/master/nova/db/main/models.py#L684-L754
16:45:30 <bauzas> agreed with gibi
16:45:48 <sean-k-mooney> i guess this would be in connection_info
16:45:54 <bauzas> yeah
16:46:01 <bauzas> that's where they're stuffing it into
16:46:09 <bauzas> and that's a text filed
16:46:12 <bauzas> field
16:46:12 <sean-k-mooney> ya so im not a fan of that either
16:46:18 <bauzas> but I don't like persisting it
16:46:27 <sean-k-mooney> this is also in teh vm xml
16:46:35 <bauzas> for multiple reasons, the first one being that this info couldn't be reliable
16:46:50 <sean-k-mooney> the storage folk apparently use db dumps for debugging more then we do
16:46:58 <sean-k-mooney> i value having it in the logs and xml more
16:47:03 <gibi> hm, if this is in the xml then a proper sos report has enough info to correlate multipath_id with volume and instance
16:47:07 <sean-k-mooney> becuase we normally dont have db dumps
16:47:10 <bauzas> even with all we know about orphaned BDMs ?
16:47:39 <gibi> or they need historical data about delete VMs?
16:47:51 <bauzas> logs will tell you tho
16:47:58 <gibi> yeah we dump the xml to debug
16:48:01 <sean-k-mooney> bauzas: to move this forward can i suggest reaching out to rajat
16:48:09 <gibi> yeah we need rajat for this
16:48:10 <bauzas> also
16:48:16 <sean-k-mooney> or putting it on the ptg topic list
16:48:32 <bauzas> this would require a blueprint at least, maybe a spec if we consider the DB change
16:48:55 <bauzas> the fact that nothing in nova reads that value makes me very reluctant at least
16:49:13 <sean-k-mooney> ya i was -1 on thi initally when i spoke to them on slack and asked them ot bring it upstream
16:49:17 <bauzas> I don't want us to create a precedent with any text field just being a brown bag for DB bumps
16:49:21 <bauzas> dumps*
16:49:24 <sean-k-mooney> i agree this is not a bug but a minor feature
16:49:51 <sean-k-mooney> to me this is out os scope but i think we should let them present there case
16:50:07 <bauzas> then we can write an AI
16:50:18 <opendevreview> Balazs Gibizer proposed openstack/nova master: [doc]Developer doc about PCI and SRIOV testing  https://review.opendev.org/c/openstack/nova/+/928834
16:51:07 <bauzas> #agreed this case sounds a feature request and requires a blueprint, which would describe the reason for that change and the solution
16:51:09 <dansmith> a db change for a thing we don't actually need would require a lot of justification for me to get behind :)
16:51:42 <bauzas> #agreed this blueprint would have to be discussed in a later nova meeting to see whether it would be specless or requiring a spec
16:51:52 <bauzas> dansmith: I think the meeting logs are clear :)
16:52:21 <bauzas> tbc, if nothing reads that BDM value, this is tech debt
16:52:22 <dansmith> yep, just chiming in
16:52:43 <bauzas> cool
16:52:52 <bauzas> I hope whoami-rajat will read the logs
16:52:57 <bauzas> and again, I'm open to chat
16:53:15 <bauzas> I think we're settled
16:53:29 <bauzas> any carried over item from last week or any new meat to digest ?
16:53:38 <bauzas> or can I call it a wrap and take a beer ?
16:54:07 <opendevreview> Balazs Gibizer proposed openstack/nova master: [doc]Developer doc about PCI and SRIOV testing  https://review.opendev.org/c/openstack/nova/+/928834
16:54:25 <sean-k-mooney> we had one other item
16:54:38 <sean-k-mooney> can we reappove the shared security group specless blueprint
16:54:41 <sean-k-mooney> for expoy
16:54:48 <sean-k-mooney> https://blueprints.launchpad.net/nova/+spec/shared-security-groups
16:55:00 <bauzas> thanks
16:55:09 <bauzas> I haven't seen it in the agenda
16:55:18 <bauzas> I have no objection for the reapproval
16:55:26 <sean-k-mooney> i think the current state of the patch is mergable, this is the one i pinged about at the start of the meeting
16:55:38 <sean-k-mooney> so it would be a easy win after rc1
16:55:51 <bauzas> sounds a quickwin as soon as RC1 branches
16:56:00 <bauzas> yeah
16:56:12 <bauzas> okay, don't hear any disagreement, so...
16:57:00 <bauzas> #agreed https://blueprints.launchpad.net/nova/+spec/shared-security-groups is accepted again as specless bp for Epoxy
16:57:09 <bauzas> that's it for me
16:57:14 <bauzas> and we're at time
16:57:22 <bauzas> thanks all
16:57:27 <bauzas> #endmeeting