Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2026-09-14
10:19:34 sean-k-mooney there are 3 main wsgi frameworks in use
10:20:02 sean-k-mooney stephen was proposing creating oslo.wsgi to maintian the paste/paste-deploy stack in a common place
10:20:22 sean-k-mooney the other two are flask adn pechan
10:21:44 stephenfin tbc, I never proposed standardizing on a framework
10:22:14 sean-k-mooney right you just wanted to have a maintained dropin for what nova ectra was using
10:22:15 stephenfin I figured if I tried, I'd be told (hopefully politely) where to go :D
10:22:26 stephenfin yeah, exactly
10:23:56 stephenfin move all the common logic from nova, cinder, manila etc. to one place, so we could (in theory) swap out the underlying lib transparently
10:24:55 sean-k-mooney zigo: i think for your outher thread we were expecting https://pypi.org/project/standard-pkg-resources/ to be used
10:25:15 sean-k-mooney unless there is a more offical repacaging
10:25:41 sean-k-mooney stephenfin: tldr debian now has setuptools 84 so paste is broken
10:26:16 sean-k-mooney since it still uses pkg_resources so without your repacaging or another one 2026.2 wont work on debian
10:26:27 stephenfin paste uses pkg_resources/entry points?
10:26:48 stephenfin what does it need to scan entry points for?
10:27:46 sean-k-mooney i dont knwo the details i just read the mail tread that was started at teh weekend
10:28:22 stephenfin ugh https://github.com/Pylons/pastedeploy/blob/81b3c1614a726544fd93c2c2974174cb35d83035/setup.cfg#L70
10:28:35 sean-k-mooney https://github.com/Pylons/pastedeploy/blob/81b3c1614a726544fd93c2c2974174cb35d83035/src/paste/__init__.py#L4
10:28:53 stephenfin we need abot 5% of what paste/paste deploy gives us
10:28:58 stephenfin *about
10:29:07 sean-k-mooney if that but ya
10:29:44 sean-k-mooney zigo: so the workaround is for nwo use standard-pkg-resources to provide pkg_resouces
10:29:59 sean-k-mooney until we can fix this properly
10:35:30 gibi sean-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:37:59 sean-k-mooney we can do that i guess, it can be worked aroudn at the hsot sleve asl weoll
10:38:01 sean-k-mooney but sure
10:38:19 ralonsoh thanks!
10:38:48 sean-k-mooney the release note is slitlgy incorect
10:39:02 sean-k-mooney ovs_create_tap is used for ml2/ovs and ml2/ovn
10:39:34 sean-k-mooney so "Open vSwitch plugin" implies the former not both
10:39:41 sean-k-mooney butthats minor
10:39:49 ralonsoh right
10:45:27 sean-k-mooney ralonsoh: gibi wehter we do an rc2 for this is debatable
10:45:39 sean-k-mooney its not a regression intoduced in this release
10:45:56 sean-k-mooney ovs_create_tap was added in 2026.1 so this feels more like a normal bug
10:46:09 sean-k-mooney that we would just backprot and release as normal
10:46:13 ralonsoh well, we change the default value. But yes, it was in 2026.1
10:46:22 ralonsoh we changed*
10:46:41 sean-k-mooney ya i guess we coudl codnier it a caindiate due to the neutron defualt change
10:47:11 gibi I guess we can make a decision on the IRC meeting today having wider core presence
10:47:16 sean-k-mooney ok i approved it and noted teh 2 workarounds
10:48:10 sean-k-mooney yep in either case we will want to backport this to 2026.1
10:49:14 sean-k-mooney so once it emerges we can do that and then just deceid fo we do a early release of os-vif or not
10:49:18 sean-k-mooney os-vif is cycle-with-intermediary
10:49:24 sean-k-mooney so we can do a release at any time
10:49:31 sean-k-mooney its not cycle-with-RC
10:49:37 sean-k-mooney so it technially does not have RCs
10:49:50 gibi do we need a requirements bump?
10:49:57 gibi to consume the new os-vif?
10:50:01 sean-k-mooney the question is more if we do the release does it quiaalfy for a requiements freeze
10:50:07 sean-k-mooney gibi: yes
10:50:29 sean-k-mooney gibi: that is what is relevent in this case will the release team accpaet a requirement freeze excption
10:50:48 sean-k-mooney but we can just do a 5.2.2 release at any time
10:51:01 sean-k-mooney it shoudl eventualy get into stable
10:51:20 sean-k-mooney it just might take a while master is already 2027.1 for os-vif
10:51:27 sean-k-mooney so it will need a backport to stabel regardless
10:51:58 gibi cc elodilles ^^
10:52:24 sean-k-mooney im basing those number on https://github.com/openstack/releases/blob/master/deliverables/hibiscus/os-vif.yaml
10:52:46 sean-k-mooney the first release of 2027.1 woudl be 5.3.0 or higher
10:57:21 sean-k-mooney gibi: ralonsoh: for what its worht i woudl not bother bumping nova or neutrons min os-vif for this
10:57:34 sean-k-mooney we may want to do that in 2027.1 jsut ebcause its been a while
10:58:22 sean-k-mooney but for 2026.2 this is a nice to have with host level workaround such as disabling ipv6 link local adresss asignemtn vai udev or sysctl
10:58:59 sean-k-mooney so while i agree its an imporntat optimization it shoudl not hold up the release
10:59:27 sean-k-mooney ralonsoh: do you know if libvirt used to do this for us by the way?
11:10:24 zigo sean-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:50 zigo I'd rather *not* use a replacement for it and fix the issue.
11:11:03 sean-k-mooney zigo: paste uses it
11:11:26 sean-k-mooney https://github.com/Pylons/pastedeploy/blob/main/src/paste/__init__.py
11:11:45 sean-k-mooney do declare a namespace package and some extention loading for the middleware
11:11:53 zigo sean-k-mooney: Ah, yeah, I have pending debian patches for it.
11:12:05 zigo I'll fix paste, and try again.
11:14:13 sean-k-mooney zigo: i didnt see an upstream pr for that by the way
11:14:22 sean-k-mooney are you planning to fix it in pastedeploy itself
11:14:33 zigo I will try.
11:15:01 sean-k-mooney we are currently creating oru downstream build artifact as well
11:15:26 sean-k-mooney so we will have to fix this in some way but not sure the best path for now
11:15:44 zigo I 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=heads
11:19:07 sean-k-mooney we are movign to building everythign directly form souce without downstream patches were possibel
11:19:14 sean-k-mooney so far we have avoided any
11:41:56 opendevreview Merged openstack/nova master: Update master for stable/2026.2 https://review.opendev.org/c/openstack/nova/+/1005514
12:00:06 opendevreview Merged 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/+/1005496
12:01:52 elodilles gibi: 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:58 elodilles nevertheless, 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:02:38 sean-k-mooney elodilles: well the lib freeze is over
12:02:58 sean-k-mooney at least on master
12:03:08 sean-k-mooney but i guess its still in place for stable 2026.2
12:03:16 sean-k-mooney until that actully has it offical release
12:03:42 sean-k-mooney i personally dont think we need to rush a master release
12:04:02 sean-k-mooney we can propsoe the backport to stable and do a release as you say in early october
12:04:11 elodilles about 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 IMHO
12:04:56 sean-k-mooney well the default change in behvior here is not really a considertaion
12:05:04 opendevreview Merged openstack/nova stable/2026.2: Update .gitreview for stable/2026.2 https://review.opendev.org/c/openstack/nova/+/1005512
12:05:06 sean-k-mooney we are accpatign this as a bug in the bevhior and its not configurabel
12:05:13 opendevreview Merged openstack/nova stable/2026.2: Update TOX_CONSTRAINTS_FILE for stable/2026.2 https://review.opendev.org/c/openstack/nova/+/1005513
12:05:59 sean-k-mooney elodilles: the tap devices really shoudl nto have any ip assigned when used with ovs period
12:06:07 sean-k-mooney on the host side
12:06:18 sean-k-mooney so if they have link local adresses or similar that a bug
12:06:31 sean-k-mooney and possibly a regresssion vs libvirt depening on what its actual beahvior was
12:06:55 sean-k-mooney we have fix similar issues in the past
12:06:59 sean-k-mooney without an expction
12:07:03 elodilles sean-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)

Earlier   Later