Earlier  
Posted Nick Remark
#openstack-nova - 2024-10-01
16:12:53 bauzas #link https://releases.openstack.org/dalmatian/schedule.html
16:12:58 bauzas #info Dalmatian GA planned tomorrow
16:13:08 tkajinam \o/
16:13:08 bauzas that will probably help RDO ^
16:13:17 bauzas #link https://releases.openstack.org/epoxy/schedule.html
16:13:33 bauzas as a reminder, we don't have yet nova deadlines for Epoxy, that will be discussed at the PTG
16:13:54 bauzas #topic Review priorities
16:14:02 bauzas #link https://etherpad.opendev.org/p/nova-2025.1-status
16:14:22 bauzas I need to do some homework and add the already approved blueprints in therre
16:15:30 bauzas at least gibi's series on igb is there
16:15:40 bauzas sounds like a quickwin
16:15:48 bauzas #topic PTG planning
16:15:54 bauzas #info as a reminder, we'll meet (virtually) at the PTG on Oct 21-25 2024
16:16:00 bauzas #info Please register yourself to the virtual PTG
16:16:07 bauzas #link https://etherpad.opendev.org/p/nova-2025.1-ptg
16:16:16 bauzas please add your topics to the above etherpad
16:16:34 bauzas the more we have before the PTG, the better we are prepared and I can write some agenda :)
16:16:56 bauzas we'll have the Austin room for the week
16:17:04 bauzas (but I think I already said that last week)
16:17:28 bauzas any questions about the PTG ?
16:17:54 gibi bauzas: will we have Asia slot?
16:18:05 bauzas for the translations docs thing with ian and sungsoo, there is a TC topic about it
16:18:28 bauzas gibi: I don't think so, seongsoo and ian had their topic in the TC etherpad
16:18:47 bauzas I'll clarify that tonight during the TC meeting
16:19:15 gibi OK, so TC won't have an Asia slot either?
16:19:31 bauzas unless of course I see a few topics in the nova PTG etherpad where the owners are in Asian TZ
16:19:52 bauzas gibi: that's the question I'll ask tonight :D
16:20:03 gibi cool:)
16:20:30 bauzas I'm fine with addressing the translation issues as a cross-project discussion
16:20:42 bauzas but I can propose nova for some experimental work
16:20:50 gibi me too, I just need to know in advance if there is an extra schedule
16:21:07 bauzas yeah, I want to prepare my mornings :)
16:21:23 bauzas should be hopefully settled next week
16:21:32 gibi those sweet lazy mornings of the PTG week :)
16:21:54 bauzas for the moment, we stick with the usual slots that are 1300-1700UTC Tues to Fri
16:22:18 gibi ack
16:22:44 bauzas #topic Stable Branches
16:22:48 bauzas elodilles: heya
16:22:56 elodilles #info stable/202*.* gates seem to be OK
16:23:09 elodilles at least i'm not aware of any issue :)
16:23:20 elodilles and some patches merged, so probably OK
16:23:27 elodilles #info note, that stable/2023.1 (antelope) will transition to unmaintained/2023.1 in a month
16:23:45 elodilles we might want a release in 1 or 2 weeks ^^^
16:23:55 bauzas time flies
16:23:56 elodilles *final* stable/2023.1 release
16:23:58 elodilles yepp
16:24:18 elodilles and that's all from me about stable for now
16:24:24 bauzas one open thought
16:24:44 bauzas but I don't want to start a flamewar now
16:24:49 elodilles :)
16:25:17 bauzas once we unmaintain 2023.1, we will only have one SLURP release
16:25:21 bauzas that's maintained
16:26:31 bauzas giving an extra month before the flag would help people who *really* follow upstream stable support envelope to have more time to upgrade to C
16:27:23 dansmith can we move this along?
16:27:40 bauzas I don't know, that's a blind question
16:29:24 bauzas you know what ? that's not the right place to discuss that and I first need to check the releases support envelopes
16:30:31 bauzas but honestly, my thought was about the fact that I can imagine a SLURP release having a shortly longer support envelope than a non-SLURP one (and don't think about LTSes, that's not what I'm thinking)
16:31:01 bauzas aw, moving on
16:31:09 elodilles bauzas: well, now i'm a bit unsure as well. but i'll check the resolution...
16:31:18 bauzas #topic vmwareapi 3rd-party CI efforts Highlights
16:31:18 elodilles (unmaintained)
16:31:27 bauzas fwiesel: around ?
16:31:53 fwiesel Not much to update from my side. Still looking into the flakyness of the CI (occasional port failing to get bound)
16:32:16 fwiesel dansmith: Gentle reminder about the open comment: https://review.opendev.org/c/openstack/nova/+/910627?tab=comments
16:32:21 fwiesel Otherwise, that's from my side.
16:32:29 bauzas cool
16:33:00 bauzas and thanks for the update, g'luck with the flakyness
16:33:07 bauzas #topic Open discussion
16:33:13 bauzas (tkajinam): How can we restore https://review.opendev.org/c/openstack/nova/+/845660 ?
16:33:39 bauzas tkajinam: your time
16:33:56 tkajinam I noticed I left that stale for long and I'm willing to resume that work
16:34:42 tkajinam the current problem is that os-brick silently falls back to single path connection in case multipath is not running. os-brick introduce the capability to hard-fail in case mulitpath is not running and that is configurable in cinder and glance, but is not in nova
16:34:49 dansmith fwiesel: ack, but it's not blocking anything
16:35:11 gibi tkajinam: yeah make sense to pick that up
16:35:28 tkajinam my main question here is whether this can be spec-less bp or need spec
16:35:53 bauzas would there be an upgrade impact ?
16:36:18 tkajinam no. the option is disabled by default so the existing behavior is kept during upgrade.
16:36:44 gibi seems like fully backward compatible opt-in behavior
16:36:46 fwiesel dansmith: No, the comment not. I assumed you were volunteering for the second required review core review and hoped I addressed everything outsstanding.
16:36:53 gibi so for me it is OK to have it as specless
16:36:59 bauzas on a rolling upgrade case, you'd then have *some* computes that would fail instance creations while some others not ?
16:36:59 tkajinam yes > full backward compatible.
16:37:35 gibi bauzas: the compute agent will fail to start up if you opt-in to the new behavior but failed to install multipathd
16:37:52 bauzas then a doc would be sufficient
16:38:14 bauzas do you plan to change the behaviour in a later cycle ?
16:38:36 tkajinam no. I think we can keep the behavior optional. that's consistent with cinder and glance for now.
16:39:18 bauzas then I'm indeed cool with a specless BP, provided we document the option correctly (only turn that flag on if you installed multipathd)
16:40:19 bauzas any disagreements ?
16:41:19 bauzas so,
16:41:44 bauzas #agreed https://blueprints.launchpad.net/nova/+spec/enforce-multipath approved as specless
16:41:59 bauzas next item
16:42:02 bauzas (tkajinam): Python 3.8 support being removed
16:42:03 tkajinam sean-k-mooney, in case you have any remaining concerns then please let me know ^^^
16:42:20 tkajinam this is again my topic :-P
16:42:51 tkajinam so as I wrote we are removing python 3.8 support from oslo. This is the timeline we agreed earlier and would move the whole projects to drop python 3.8 support
16:43:32 tkajinam AFAIK py38 job was removed from most of the nova/placement repos but there are a few remaining in placement I'm trying to replace. if you can review the change and also double-check the other repos, that would be nice
16:43:40 bauzas py3.8 upstream support is planned end of Nov, right?
16:43:57 bauzas upstream support end*
16:44:20 tkajinam https://devguide.python.org/versions/ it's reaching its EOL this month
16:44:29 bauzas oh this month

Earlier   Later