Monday, 2026-09-14

« Saturday, 2026-09-12 Index Tuesday, 2026-09-15 »
opendevreviewfivetime proposed openstack/os-vif master: ovs: disable IPv6 on taps created by create_tap before bringing them up  https://review.opendev.org/c/openstack/os-vif/+/100549604:35
*** elodilles_ooo is now known as elodilles08:11
ralonsohHi folks, we have a patch that could be affecting the ipv6 tempest and neutron-tempest-plugin tests when using ipv608:36
ralonsohhttps://review.opendev.org/c/openstack/os-vif/+/100549608:36
ralonsohwell, not only the tests08:36
ralonsohthat was triggered since `create_tap=True`08:37
ralonsohplease, if you have a few minutes, check it. Thanks in advance!08:37
opendevreviewOpenStack Release Bot proposed openstack/nova stable/2026.2: Update .gitreview for stable/2026.2  https://review.opendev.org/c/openstack/nova/+/100551209:10
opendevreviewOpenStack Release Bot proposed openstack/nova stable/2026.2: Update TOX_CONSTRAINTS_FILE for stable/2026.2  https://review.opendev.org/c/openstack/nova/+/100551309:11
opendevreviewOpenStack Release Bot proposed openstack/nova master: Update master for stable/2026.2  https://review.opendev.org/c/openstack/nova/+/100551409:11
opendevreviewKamil Sambor proposed openstack/nova master: Fix pickling error that forces oslo.service to fall back to fork  https://review.opendev.org/c/openstack/nova/+/100095609:39
bauzashuzzah, got spammed by Launchpad about bugfixes released for RC1 !09:42
bauzaswelcome Indri :)09:43
gibiralonsoh: is this something that you feel like a RC2 candidate?09:49
gibior can it wait for Hibiscus GA and then backported?09:56
ralonsohgibi, I think this should be in RC210:00
ralonsohbecause we made `create_tap=True` in 2026.210:00
ralonsohbut not strong opinions, if needed, we can backport it later10:01
zigosean-k-mooney: Hi there! Building Nova Hibiscus, the only failure is one test you wrote last June. The stack dump is:10:12
zigohttps://paste.opendev.org/show/bFVnIK7uYPZCOwpkF9Xa/10:12
zigoYour thoughts?10:12
sean-k-mooneythis was part of fixing the json log formating10:17
sean-k-mooneywe ahd an issue whta only manifest if you enabeld the json formaitng in oslo10:18
sean-k-mooneythe specific issue is not familarure but i can take a look10:18
sean-k-mooneyzigo: by the way pkg_resoucres is not its own package10:19
sean-k-mooneybut we shoudl talks to stephenfin about your mail thread10:19
sean-k-mooneythere are 3 main wsgi frameworks in use10:19
sean-k-mooneystephen was proposing creating oslo.wsgi to maintian the paste/paste-deploy stack in a common place10:20
sean-k-mooneythe other two are flask adn pechan10:20
stephenfintbc, I never proposed standardizing on a framework10:21
sean-k-mooneyright you just wanted to have a maintained dropin  for what nova ectra was using10:22
stephenfinI figured if I tried, I'd be told (hopefully politely) where to go :D10:22
stephenfinyeah, exactly10:22
stephenfinmove all the common logic from nova, cinder, manila etc. to one place, so we could (in theory) swap out the underlying lib transparently10:23
sean-k-mooneyzigo: i think for your outher thread we were expecting https://pypi.org/project/standard-pkg-resources/ to be used 10:24
sean-k-mooneyunless there is a more offical repacaging10:25
sean-k-mooneystephenfin: tldr debian now has setuptools 84 so paste is broken10:25
sean-k-mooneysince it still uses pkg_resources so without your repacaging or another one 2026.2 wont work on debian10:26
stephenfinpaste uses pkg_resources/entry points?10:26
stephenfinwhat does it need to scan entry points for?10:26
sean-k-mooneyi dont knwo the details i just read the mail tread that was started at teh weekend10:27
stephenfinugh https://github.com/Pylons/pastedeploy/blob/81b3c1614a726544fd93c2c2974174cb35d83035/setup.cfg#L7010:28
sean-k-mooneyhttps://github.com/Pylons/pastedeploy/blob/81b3c1614a726544fd93c2c2974174cb35d83035/src/paste/__init__.py#L410:28
stephenfinwe need abot 5% of what paste/paste deploy gives us10:28
stephenfin*about10:28
sean-k-mooneyif that but ya10:29
sean-k-mooneyzigo: so the workaround is for nwo use standard-pkg-resources to provide pkg_resouces10:29
sean-k-mooneyuntil we can fix this properly10:29
gibisean-k-mooney: could you take a look at https://review.opendev.org/c/openstack/os-vif/+/1005496 ? ralonsoh suggest it as an RC2 trigger. cc Uggla 10:35
sean-k-mooneywe can do that i guess, it can be worked aroudn at the hsot sleve asl weoll10:37
sean-k-mooneybut sure10:38
ralonsohthanks!10:38
sean-k-mooneythe release note is slitlgy incorect10:38
sean-k-mooneyovs_create_tap is used for ml2/ovs and ml2/ovn10:39
sean-k-mooneyso "Open vSwitch plugin" implies the former not both10:39
sean-k-mooneybutthats minor10:39
ralonsohright10:39
sean-k-mooneyralonsoh: gibi  wehter we do an rc2 for this is debatable10:45
sean-k-mooneyits not a regression intoduced in this release10:45
sean-k-mooneyovs_create_tap was added in 2026.1 so this feels more like a normal bug10:45
sean-k-mooneythat we would just backprot and release as normal10:46
ralonsohwell, we change the default value. But yes, it was in 2026.110:46
ralonsohwe changed*10:46
sean-k-mooneyya i guess we coudl codnier it a caindiate due to the neutron defualt change10:46
gibiI guess we can make a decision on the IRC meeting today having wider core presence10:47
sean-k-mooneyok i approved it and noted teh 2 workarounds10:47
sean-k-mooneyyep in either case we will want to backport this to 2026.110:48
sean-k-mooneyso once it emerges we can do that and then just deceid fo we do a early release of os-vif or not10:49
sean-k-mooneyos-vif is  cycle-with-intermediary10:49
sean-k-mooneyso we can do a release at any time10:49
sean-k-mooneyits not  cycle-with-RC10:49
sean-k-mooneyso it technially does not have RCs10:49
gibido we need a requirements bump?10:49
gibito consume the new os-vif?10:49
sean-k-mooneythe question is more if we do the release does it quiaalfy for a requiements freeze10:50
sean-k-mooneygibi: yes10:50
sean-k-mooneygibi: that is what is relevent in this case will the release team accpaet a requirement freeze excption10:50
sean-k-mooneybut we can just do a 5.2.2 release at any time10:50
sean-k-mooneyit shoudl eventualy get into stable10:51
sean-k-mooneyit just might take a while master is already 2027.1 for os-vif10:51
sean-k-mooneyso it will need a backport to stabel regardless10:51
gibicc elodilles ^^10:51
sean-k-mooneyim basing those number on https://github.com/openstack/releases/blob/master/deliverables/hibiscus/os-vif.yaml10:52
sean-k-mooneythe first release of 2027.1 woudl be 5.3.0 or higher10:52
sean-k-mooneygibi: ralonsoh: for what its worht i woudl not bother bumping nova or neutrons min os-vif for this10:57
sean-k-mooneywe may want to do that in 2027.1 jsut ebcause its been a while10:57
sean-k-mooneybut for 2026.2 this is a nice to have with host level workaround such as disabling ipv6 link local adresss asignemtn vai udev or sysctl10:58
sean-k-mooneyso while i agree its an imporntat optimization it shoudl not hold up the release10:58
sean-k-mooneyralonsoh: do you know if libvirt used to do this for us by the way?10:59
zigosean-k-mooney: The removal of pkg_resources happened in Debian on the 11th, which is the day of the RC1. Setuptools 84 was uploaded to Unstable. But I think I nearly recovered from it. From where is pkg_resources needed ? I can't see any trace of it in Nova with a grep.11:10
zigoI'd rather *not* use a replacement for it and fix the issue.11:10
sean-k-mooneyzigo: paste uses it11:11
sean-k-mooneyhttps://github.com/Pylons/pastedeploy/blob/main/src/paste/__init__.py11:11
sean-k-mooneydo declare a namespace package and some extention loading for the middleware11:11
zigosean-k-mooney: Ah, yeah, I have pending debian patches for it.11:11
zigoI'll fix paste, and try again.11:12
sean-k-mooneyzigo: i didnt see an upstream pr for that by the way11:14
sean-k-mooneyare you planning to fix it in pastedeploy itself11:14
zigoI will try.11:14
sean-k-mooneywe are currently creating oru downstream build artifact as well11:15
sean-k-mooneyso we will have to fix this in some way but not sure the best path for now11:15
zigoI have this one already: https://salsa.debian.org/python-team/packages/pastescript/-/blob/debian/master/debian/patches/do-not-use-pkg_resource.patch?ref_type=heads11:15
sean-k-mooneywe are movign to building everythign directly form souce without downstream patches were possibel11:19
sean-k-mooneyso far we have avoided any11:19
opendevreviewMerged openstack/nova master: Update master for stable/2026.2  https://review.opendev.org/c/openstack/nova/+/100551411:41
opendevreviewMerged openstack/os-vif master: ovs: disable IPv6 on taps created by create_tap before bringing them up  https://review.opendev.org/c/openstack/os-vif/+/100549612:00
elodillesgibi: sean-k-mooney: ralonsoh: so about os-vif: it's a library, doesn't have RCs. so it can be released anytime, yes. but since we are in lib freeze already, we should avoid releasing. it's not impossible, but should be avoided. (note that requirements still not branched to stable/2026.2; but if we release, then we need to negotiate with *Requirements* team that the bump can be done). 12:01
elodillesnevertheless, if the bug is not release critical (it exists since 2026.1 release, so i guess not), then we can wait and release AFTER the official coordinated 2026.2 Hibiscus release, let's say, one week after that, early October.12:01
sean-k-mooneyelodilles: well the lib freeze is over12:02
sean-k-mooneyat least on master12:02
sean-k-mooneybut i guess its still in place for stable 2026.212:03
sean-k-mooneyuntil that actully has it offical release12:03
sean-k-mooneyi personally dont think we need to rush a master release12:03
sean-k-mooneywe can propsoe the backport to stable and do a release as you say in early october12:04
elodillesabout backportability: it's again a nova team decision. if the team decides, that the bug fix is so important, that it needs to be backported despite the 'default config change', then it can work as an "exception in the process", though, i'd rather backport it without default value change AND notify the users that the value should be changed to avoid XY bug. that is less destructive IMHO12:04
sean-k-mooneywell the default change in behvior here is not really a considertaion12:04
opendevreviewMerged openstack/nova stable/2026.2: Update .gitreview for stable/2026.2  https://review.opendev.org/c/openstack/nova/+/100551212:05
sean-k-mooneywe are accpatign this as a bug in the bevhior and its not configurabel12:05
opendevreviewMerged openstack/nova stable/2026.2: Update TOX_CONSTRAINTS_FILE for stable/2026.2  https://review.opendev.org/c/openstack/nova/+/100551312:05
sean-k-mooneyelodilles: the tap devices really shoudl nto have any ip assigned when used with ovs period12:05
sean-k-mooneyon the host side12:06
sean-k-mooneyso if they have link local adresses or similar that a bug12:06
sean-k-mooneyand possibly a regresssion vs libvirt depening on what its actual beahvior was12:06
sean-k-mooneywe have fix similar issues in the past12:06
sean-k-mooneywithout an expction12:06
elodillessean-k-mooney: i think lib freeze is in place as long as openstack/requirements is not branched. (i just came back from summit and haven't had the chance to catch up on all things, so I have to check what's the state of things)12:07
sean-k-mooneyoh requiremetn has not branched yet12:07
sean-k-mooneyi tought that happend on firday12:07
sean-k-mooneyah your right not yet12:07
elodillessean-k-mooney: by exception here i mean, that "we should avoid things based on stable policy, but the team decides, that despite it's against the policy, the team accepts to backport it anyway" o:)12:10
sean-k-mooneyright but that only applies to configable changes12:10
sean-k-mooneywe whoudl not avoid fixign broken behvior in a backport12:11
elodilles+112:11
sean-k-mooneynova/libvirt has historcally disbaled thing like this in verias code paths12:12
sean-k-mooneythe issue here is we are movign the management form libvirt to os-vif and there is a default change in neutron that expsoes the behvior delta12:12
sean-k-mooneywe added the fucntionatly in os-vif last cycel but we defautled to the old behvior12:12
sean-k-mooneyin this cycle neutron has update dthe defualt to use os-vif12:12
sean-k-mooneyso the ipv6 link local issue is now more apprent12:13
sean-k-mooneythis is one of those things that is also somewhat disto dependent as  the defautl for things like " do all itnerface get link local adresses" depend on the distro12:14
sean-k-mooneywe try to normalise this behvior in os-vif when it impact perfromacne or security12:14
sean-k-mooneyfor example if we create a bridge we disabel ipv6 entrily https://github.com/openstack/os-vif/blob/master/vif_plug_ovs/linux_net.py#L127-L138 for the saem reason12:15
elodillesah I see. :S so if i understand it well, this is really something that should already be part of 2026.2 Hibiscus coordinated release, right?12:27
elodillesanyway, if the team is confident that this does not bring any regression AND it is safe for a late os-vif release and version bump, then I think release team is OK with it (at least, me o:)) and requirements team probably same, too. *I* think.12:31
elodillesbut this should happen ASAP :X12:34
ralonsoh(sorry, I was in a meeting, checking now the messages)12:49
ralonsohsean-k-mooney, so I think you'll backport it to 2026.2, right?12:51
opendevreviewStephen Finucane proposed openstack/nova master: api: Drop Paste dependency  https://review.opendev.org/c/openstack/nova/+/100556313:33
stephenfinsean-k-mooney: zigo: ☝️ Probably too late for Hibiscus, though we could backport it after the release13:33
sean-k-mooneystephenfin: that droping paste ranther then pastedeploy right13:37
stephenfinthat's part of the code I ultimately wanted to have in oslo.wsgi, but I haven't got that ready yet13:37
stephenfinsean-k-mooney: yep. pastedeploy is still semi-maintained13:37
sean-k-mooneyack just confirming13:37
stephenfinand doesn't depend on paste13:37
sean-k-mooneyok i was not sure about htat aspect13:37
sean-k-mooneywhat we really need in oslo.wsgi woudl be a parser for the api-paste.ini and standalone implemation of the pipeline/middelware loading/cofniguration13:38
sean-k-mooneyhow that is integrated into the relvent frameworks however is framework dependent13:39
stephenfinagreed. That had been my plan13:41
stephenfineffectively vendor the useful parts of pastedeploy and cull the rest13:41
stephenfinvendor/rewrite13:42
sean-k-mooneyya for cybrog we may rewrite given teh other api work i expect in the future but on the other hand im hoping to pace that change with the other work we need to focus on13:52
sean-k-mooneythe api is small but still.13:52
sean-k-mooneywatcher uses pastedeploy without supprot for api-paste.ini13:53
sean-k-mooneyit has a hardcode pipeline so it needs it even less13:53
sean-k-mooneyporting nova to something else woudl be a lot of work as you know better then most13:54
opendevreviewDaniel Schulz proposed openstack/nova master: Prevent orphaned attachments by preemptive delete  https://review.opendev.org/c/openstack/nova/+/100243914:51
opendevreviewDaniel Schulz proposed openstack/nova master: Add regression test for https://bugs.launchpad.net/nova/+bug/2167250  https://review.opendev.org/c/openstack/nova/+/100558714:51
opendevreviewDaniel Schulz proposed openstack/nova master: Prevent orphaned attachments by preemptive delete  https://review.opendev.org/c/openstack/nova/+/100243914:59
opendevreviewsean mooney proposed openstack/os-vif stable/2026.2: ovs: disable IPv6 on taps created by create_tap before bringing them up  https://review.opendev.org/c/openstack/os-vif/+/100559115:11
UgglaReminder: Nova upstream meeting in ~30mn15:32
elodillesUggla: i think there is an issue with your editing of Nova Meeting page at line "#info Nova deadlines are set in the above schedule". the "<!--" is not closed with "-->" o:)16:00
opendevreviewDaniel Schulz proposed openstack/nova master: Add regression test for https://bugs.launchpad.net/nova/+bug/2167250  https://review.opendev.org/c/openstack/nova/+/100558716:01
opendevreviewDaniel Schulz proposed openstack/nova master: Prevent orphaned attachments by preemptive delete  https://review.opendev.org/c/openstack/nova/+/100243916:01
Uggla#startmeeting nova16:01
opendevmeetMeeting started Mon Sep 14 16:01:50 2026 UTC and is due to finish in 60 minutes.  The chair is Uggla. Information about MeetBot at http://wiki.debian.org/MeetBot.16:01
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.16:01
opendevmeetThe meeting name has been set to 'nova'16:01
UgglaHello everyone16:01
gibio/16:02
tkajinamo/16:02
elodilleso/16:02
gmaano/16:02
Leo[m]o/16:02
bauzaso/16:03
Ugglalet's start16:03
Uggla#topic Bugs (stuck/critical) 16:03
Uggla#info No Critical bug16:03
dansmitho/16:04
Uggla#topic Gate status 16:04
fwieselo/16:04
Uggla#link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs 16:04
gibiheads up we made openstack-tox-cover on nova non-voting during the weekend to make RC1 possible as it was hanging a lot16:04
Uggla#link https://etherpad.opendev.org/p/nova-ci-failures-minimal16:04
Uggla#link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&branch=stable%2F*&branch=master&pipeline=periodic-weekly&skip=0 Nova&Placement periodic jobs status16:04
dansmiththe cover job has no unique voting function anyway, so no rush to put it back IMHO16:04
gibithe tox cover issue tracked in https://bugs.launchpad.net/nova/+bug/216708816:04
gmaanas that is along running job also which take time to pass the test only changes16:05
Ugglagibi, you ruin my surprise effect about tox-cover. :)16:05
gibiit feels like it hits a valid hang somewhere in the functional test16:05
gibiUggla: sorry :)16:05
Ugglanw16:05
gibiI don't like surprises ;)16:05
gmaani am worried that is not caught in functional job?16:05
lajoskatonao/16:05
gibithere is some hang in the functional job too but less frequent16:06
gmaank16:06
gibiI haven't rootcaused it yet to say it is the same16:06
gibiI will work on this as my time allows16:06
gibiat least the tox cover hand is pinpointed to two test cases16:06
gibiwith a somewhat usabel local reproducer16:07
gibianyhow we can move on16:07
Ugglathx gibi16:07
Uggla#topic Release Planning 16:07
Uggla#link https://releases.openstack.org/hibiscus/schedule.html16:07
Uggla#info Nova deadlines are set in the above schedule16:07
Uggla#info PTG etherpad for 2027.1 is available: https://etherpad.opendev.org/p/nova-2027.1-ptg (also set in the nova topic)16:07
Uggla#info RC1 release patch merged. Thx elodilles16:07
elodillesthx too Uggla o:)16:08
gibiit was a long weekend :)16:08
Uggla#topic Review priorities 16:08
UgglaUnsure about the need of RC2.16:09
elodillesgibi: oh, and thx to you as well for the RC1 patch update ;)16:09
Ugglaanyway let's move on 16:10
Uggla#topic Stable Branches 16:10
elodillesUggla: is there any release critical issue? :-o\16:10
* Uggla giving the mic to elodilles16:11
UgglaI saw earlier discussion with Sean about a possible patch missing.16:11
UgglaBut I have not read yet. So Would rather not say something wrong16:11
elodillesah, OK. fingers crossed16:12
elodillesabout stable:16:12
elodilles#info we have now stable/2026.2 branch for every project16:12
elodilles#info stable gates should be OK (I'm not aware of any stable gate issue)16:12
elodilles#info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci16:12
* elodilles passes back the mic to Uggla 16:12
Ugglathx elodilles16:13
* gibi_ is lagging like hell16:13
Uggla#topic vmwareapi 3rd-party CI efforts Highlights16:13
fwieselHi, no updates from my side.16:13
Ugglathx fwiesel16:13
Uggla#topic Nova using openstack sdk for neutron16:14
Ugglalajoskatona something you'd like to share?16:14
lajoskatonaI updated some of the patches 2 weeks ago to use the new SDK, but last week I travelled so no fresh news16:15
Ugglaok good thx16:15
Uggla#topic Bug scrubbing 16:16
Uggla#info up to 70 (+3).16:16
Uggla#link https://etherpad.opendev.org/p/nova-bug-triage-roster16:16
Uggla#link https://truc.uggla.fr/ to follow the trend.16:16
Uggla#info Next meeting (next week): [public] Upstream bug triage. Wednesday, Septembre 16th · 15:30 – 16:00 UTC. Video call link: meet.google.com/zjr-rxus-hzj16:17
Uggla#topic Open discussion16:17
Uggla(sean): reappoveal of https://blueprints.launchpad.net/nova/+spec/support-vfio-variant-driver-managed-mode-via-cyborg for 2027.116:17
* Uggla pass the mic to sean-k-mooney16:18
Ugglaok let's switch topic because Sean seems not available.16:20
Uggla(gibi): proposal for nova-reviewer group16:20
* Uggla giving the mic to gibi16:20
gibi_o/ slight correction to that16:20
gibi_I think the "how to populate the new nova-reviewer group?" question need some preparation before the PTG.16:20
gibi_gmaan already indicated that the review comments in https://review.opendev.org/c/openstack/nova/+/986141 not his preferred way for discussing this.16:20
gibi_So I'm raising here, how should we prepare this topic to the PTG so that we spend the time finding consensus instead of spending the time formulating and explaining opinions.16:21
gibi_I mean on the PTG time window we should focus on finding consesus16:21
gibi_rather that gathering ideas16:21
gmaanyeah, its good to discuss in PTG than gerrit16:21
gibi_I think we need to do the gathering ideas and understanding each outhers viewpoint before the PTG16:22
bauzasagreed with gibi16:22
gmaan++16:22
Uggla++16:22
gibi_so the question how to do that?16:23
gibi_I added some lazy strawmans in the doc patch16:23
gibi_https://review.opendev.org/c/openstack/nova/+/98614116:23
gibi_but I hear you gmaan that review comments might not be a best format for it16:24
gibi_For me it would be helpful to see other's oppinions before the actual PTG and be able to ask clarifying question about it to understand them.16:24
gibi_and I can also do a braindump myself so other can see it16:24
gmaanyeah, i think we can start with what current criteria/expectation are to become nova-core for the nova-reviewers also and we can see what all we can change or add?16:25
bauzas++16:25
bauzasI can add my thoughts too in the patch16:25
gibi_should I put my views in an etherpad? mail? on that doc patch?16:26
gmaaneven it is from adjacent service reviewer/core, i feel strongly that we should not make it volunteer basis or because they are core in other service quality for nova-reviewer16:26
gmaangibi_: i prefer in etherpad if we are going to discuss in PTG16:26
gibi_I'm OK with an etherpad (I don't like email that much)16:27
gibi_So I will dump into the PTG one my ideas. Lets try to focus on understanding each other before we start debating. Shall we?16:27
gmaanyeah, thanks gibi_ 16:28
Ugglasounds good16:28
gmaani mean sounds good to me but other can tell their preferece too16:28
gmaanbut i agree that email are hard to read and get consensus 16:28
bauzasI'd be prefering to help nova reviewers instead of other service reviewers but let's discuss this in the etherpad16:28
gibi_OK sounds like we have the next step. Thanks16:29
gibi_Uggla: back to you16:29
Ugglathx gibi_16:29
UgglaAnything else you'd like to discuss ?16:30
Leo[m] Hello16:30
Leo[m]Just wanted to circle back on my spec about using hostname for ceph mon references: https://review.opendev.org/c/openstack/nova-specs/+/100009816:31
sean-k-mooneyo/16:31
Leo[m]It's been up for a while and I was hoping to get someone to look at it16:31
Leo[m]Please let me know if there is anything else I can do on my end16:32
sean-k-mooneyLeo[m]: i assume you mean dns name so FQDN16:32
sean-k-mooneynot hostname16:32
Leo[m]Yes, the intention is to use a generic CNAME record so the ceph mons can change without needing to change the references in Nova16:32
sean-k-mooneyUggla: for my topic i wanted to ask can we reappove the cybrog manage mode specless bluepint for this cycle16:33
sean-k-mooneyit missed last cycel because of the cyborg side not nova so im hopign stephen and Melanie will be fine with revieing it this cycle16:33
sean-k-mooneyLeo[m]: if the entire tech stack supprot that i think that woudl be infinetly better then the situation we have today16:34
Ugglasean-k-mooney ok but will it need changes on the nova side ?16:34
tkajinamLeo[m], maybe the right path is to propose that topic to the upcoming ptg and discuss details there, while that would attract attentions from cores.16:35
sean-k-mooneyyes but i have written those its a very small patch16:35
Ugglatkajinam ++16:35
sean-k-mooneyUggla: like -20+300 lines16:35
tkajinammaybe it's a good timing to create an etherpad to gather topics ?16:35
sean-k-mooneyUggla: if it didnt need nova change it woudl not have a nova blueprint :)16:35
Ugglatkajinam done16:35
tkajinamUggla++16:36
* Uggla realize it was a stupid question :)16:36
sean-k-mooneyhttps://review.opendev.org/c/openstack/nova/+/99457916:36
sean-k-mooneythat is the entirity of the patch16:36
Leo[m]What would it take to propose the change at the upcoming PTG?16:36
sean-k-mooneyLeo[m]: you just need to add it to the adgenda16:37
sean-k-mooneyand Uggla  will help you find a spot16:37
sean-k-mooney*time16:37
Leo[m]Ok. I don't want to take up too much time for such a small change16:38
sean-k-mooneyits an imporant operational pain point16:38
sean-k-mooneyso i think its size is not the thing to focus on :)16:38
sean-k-mooneyLeo[m]: i have not looked at the spec yet16:39
sean-k-mooneybut the main aspect i would ask is how do we upgrade to this16:39
sean-k-mooneyper host config options are not a good path16:39
sean-k-mooneyat least not long term16:39
sean-k-mooneyas they cause issues with live migration16:39
sean-k-mooneybut ya we can work out those details later16:39
UgglaLeo[m] usually we discuss topic at PTG and then the changes are reviewed.16:39
Leo[m]What do you mean by "per host config options"?16:40
Leo[m]Sounds good. Does that mean I should prepare the PR now?16:40
sean-k-mooneyideally we woudl not bave a boolen config flage  to opt into using the hostname16:41
sean-k-mooney```As currently proposed, one config option will be added16:41
sean-k-mooney(a boolean in ``[libvirt]``, default ``False``) that allows operators16:41
sean-k-mooneyto opt in to using hostnames for the mon addresses```16:41
Ugglaonly spec is required, but if you have a "draft" patch that something helpful.16:41
sean-k-mooneynova get the ceph mon info from the ceph.conf16:42
Leo[m]Ok, great. Thank you for your help. Is there a link to information about the PTG and its agenda?16:43
sean-k-mooneyso ideally the mon adresses there woudl jsut eb updated to the fqdn and nova would "just work"16:43
sean-k-mooneynote that nova access ceph in 2 ways16:44
UgglaLeo[m] https://etherpad.opendev.org/p/nova-2027.1-ptg16:44
sean-k-mooneywe use the ceph cli and the pythyon bi9nding so we need a coherent story for both16:44
tkajinamput your topic at the bottom16:44
sean-k-mooneyso in the interest of time, are we ok with updateign https://blueprints.launchpad.net/nova/+spec/support-vfio-variant-driver-managed-mode-via-cyborg to 2027.1 and seting it back to approved?16:46
sean-k-mooneyUggla: you marked it as implemnted on last week but i reset it because its still in progress hence its current state16:46
Ugglasean-k-mooney ok16:46
gibi_sean-k-mooney: any findings from the original plans during the implementation?16:47
Ugglaso I might have write something wrong in HL/prelude.16:47
sean-k-mooneygibi_: just that the cybrog side needed me to implment ovo indirection api..16:47
gibi_sean-k-mooney: ack that probably not affecting nova :)16:48
sean-k-mooneygibi_: i realised late that we didnt have that in cybrog so i paused the work to focus on other features16:48
sean-k-mooneyso my plan is to complete the cybrog work includign ci then update the nova patch once im happy with all of that16:48
sean-k-mooneyim not expecting any scope change on the nova side for this specificly16:49
sean-k-mooneyi hae some ptg topic like using the sdk to talk to cybrog proerply16:49
sean-k-mooneybut that independint of this feature16:49
gibi_sean-k-mooney: sounds good to me16:49
gibi_Uggla: if this is in the prelude and highlight the we need to get remove it :)16:50
sean-k-mooneyi dont htink this is is there16:50
sean-k-mooneyi think we called out the mdev support16:50
sean-k-mooneythat did merge16:50
sean-k-mooneyso the nvidia drvier in thery shoudl now work16:50
Ugglayep but I extended with variant because I thought it was merged.16:51
sean-k-mooneyoh ok16:51
sean-k-mooneyalmost but not quite16:52
sean-k-mooneyah i see https://docs.openstack.org/releasenotes/nova/2026.2.html16:53
sean-k-mooneyya i can push a fix for that if you want16:53
sean-k-mooneywell this is the current text16:53
sean-k-mooney```Nova’s libvirt driver now supports Cyborg-managed mediated devices (such as vGPUs) via a new MDEV accelerator request binding type. Operators can choose to manage vGPU/mdev lifecycle through Cyborg as an alternative to Nova’s native support. Both management paths coexist safely thanks to a new OWNER_NOVA trait that prevents scheduling collisions between Nova-managed and16:54
sean-k-mooneyCyborg-managed devices.```16:54
sean-k-mooneythat does not mention manage mode16:54
sean-k-mooneyso i think we are good16:54
Ugglayep16:55
gibi_cool then16:55
sean-k-mooneyok so jsut to be clear gibi_ Uggla  are you ok with markign this as approved again for this cycle16:55
Ugglayep16:56
sean-k-mooneyif so we can move on/finsh up for this week16:56
gibi_6yepp16:56
sean-k-mooneycool thanks16:56
gibi_one queston before we stop16:56
gibi_are we then OK no to have an RC2 for the os-vif change being bumped into nova's min requirements?16:57
sean-k-mooneywe could its not stricly needed but i dont object16:57
gibi_https://review.opendev.org/c/openstack/os-vif/+/100549616:57
sean-k-mooneythat a diffent question16:58
sean-k-mooneyyour asking are we ok requestign a lib freeze excption for os-vif16:58
sean-k-mooneya min verison bump in nova would not pick that up16:58
sean-k-mooneysince its not released16:58
gibi_I'm asking, does we as the compute team needs to anyting with this in connection with the Hibiscus GA :)16:58
sean-k-mooney:) it would be nice to have but could come later, neutron would like for that to be backported and released 16:59
sean-k-mooneyhere is the backport https://review.opendev.org/c/openstack/os-vif/+/100559116:59
sean-k-mooneydoing an early release or asking for an expction work for me17:00
sean-k-mooneyearly meaing in early october when the lib freeze lifts17:00
sean-k-mooneyoh good/bad timeing not sure how muhc of that gibi_ saw17:02
gibinot much17:02
gibii started lagging again17:02
Uggla2nd option looks simpler.17:02
gibiand reconnect took time17:03
sean-k-mooneyso second option is we merge the backport17:03
sean-k-mooneyand propsoe the release wehn we are allowed too in early october17:03
sean-k-mooneybut dont need to do anything else now17:03
gibiOK 17:03
gibithat works for me17:04
UgglaI'm ok with that.17:04
gibiif nobody objects then this is cheap17:04
gibithanks17:04
gibiI have nothing further17:04
sean-k-mooneygibi: if your internet coperates this is the  backport https://review.opendev.org/c/openstack/os-vif/+/100559117:04
gibisure17:04
gibionly IRC is problematic which is strange17:04
elodillessounds OK to me with my relmgt core hat on d:)17:04
sean-k-mooneyeven better :)17:05
Ugglaok so I think we are done for today.17:05
sean-k-mooney+117:05
UgglaThanks for joining this meeting. Have a nice day/evening.17:05
Uggla#endmeeting17:05
opendevmeetMeeting ended Mon Sep 14 17:05:49 2026 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)17:05
opendevmeetMinutes:        https://meetings.opendev.org/meetings/nova/2026/nova.2026-09-14-16.01.html17:05
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/nova/2026/nova.2026-09-14-16.01.txt17:05
opendevmeetLog:            https://meetings.opendev.org/meetings/nova/2026/nova.2026-09-14-16.01.log.html17:05
gibithanks 17:05
elodillesthanks o/17:06
lajoskatonao/17:10
Leo[m]thanks o/17:10
opendevreviewMerged openstack/os-vif stable/2026.2: ovs: disable IPv6 on taps created by create_tap before bringing them up  https://review.opendev.org/c/openstack/os-vif/+/100559117:19
opendevreviewClif Houck proposed openstack/nova stable/2025.1: Parallelize per-node resource updates  https://review.opendev.org/c/openstack/nova/+/100511918:19
opendevreviewAshish Gupta proposed openstack/nova master: Fix init_host crash migration test under native threading  https://review.opendev.org/c/openstack/nova/+/100136919:18
opendevreviewGhanshyam Maan proposed openstack/nova master: [func test]Catch hanging task at graceful shutdown  https://review.opendev.org/c/openstack/nova/+/100326619:21
opendevreviewmelanie witt proposed openstack/nova master: Remove physical_network from ARQ binding profile  https://review.opendev.org/c/openstack/nova/+/100562319:46
melwittsean-k-mooney: ^19:47
« Saturday, 2026-09-12 Index Tuesday, 2026-09-15 »

Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!