[oslo][release][requirement] FFE request for oslo.context
Hello, I'd like to request an exception to merge a change[1] to oslo.context and create a new stable/2024.1 release. This change is required to fix the problem which is current blocking us from bumping oslo.messaging to the final 2024.2 release version (14.7.0)[2]. The change is small and has quite limited impact. I've tested the modification locally and confirmed it fixes the heat unit tests. [1] https://review.opendev.org/c/openstack/oslo.context/+/910153 [2] https://review.opendev.org/c/openstack/requirements/+/909906 -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit
Hi there, Happy to approve this as an FFE. Although if we can get the release out in the next few days. It'll just be a last minute release rather and FFE :) On Wed, 28 Feb 2024 at 02:28, Takashi Kajinami <kajinamit@oss.nttdata.com> wrote:
Hello,
I'd like to request an exception to merge a change[1] to oslo.context and create a new stable/2024.1 release. This change is required to fix the problem which is current blocking us from bumping oslo.messaging to the final 2024.2 release version (14.7.0)[2].
The change is small and has quite limited impact. I've tested the modification locally and confirmed it fixes the heat unit tests.
[1] https://review.opendev.org/c/openstack/oslo.context/+/910153 [2] https://review.opendev.org/c/openstack/requirements/+/909906
-- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit
-- Yours Tony.
On 2/28/24 09:45, Tony Breeds wrote:
Hi there, Happy to approve this as an FFE. Although if we can get the release out in the next few days. It'll just be a last minute release rather and FFE :)
Hi there! Well technically, the non-client libs like Oslo were supposed to be released last week according to the schedule, which is why I (and probably others) began packaging them. I'm not against a FFE if needed. Though this really *IS* a FFE, and not a "last minute release" as you worded. Please do remember that any artifact upgrade *after* the planned schedule means double work for package maintainers (and everyone else downstream), which is why we try to follow the schedule, have freeze time, and have FFE when needed. Cheers, Thomas Goirand (zigo)
I've received similar feedback in a few other places. This is becoming off-topic from the original FEE discussion but probably it's worth discussing now to avoid the same confusion in the future. The main factor here is that we create releases at the freeze timing, and then start testing the releases AFTER the freeze, when requirement bump is proposed. This means that any problems found after the release immediately become exceptions. Because of oslo's nature, it's quite difficult to catch all problems in oslo side (we can't run all tests from all projects to gate any change). If we more strictly aim non-client lib freeze then we may need to change some of our workflows here 1. Create the final releases some time BEFORE the freeze 2. Each project adds CI jobs with oslo master to catch problems early 3. Send out email for requirement CI failure to get more attention from project side # From my view, quite limited people other than requirements team pay attention to requirement CI failure, # which sometimes delays fixing the problems caused by library changes. Another factor I'd like to raise is the negligence to deprecation. There are multiple functionalities in oslo which were deprecated some time ago, but literally every time we attempt to remove these, we face the situation where these really old items are still used in some of the projects, with noisy warning ignored for years. The recent situation with sqlalchemy-migrate and sql-a is a clear example I'd say. I'd like to take this time to ask all to pay some more attentions to these ... Finally, please be mindful that oslo team is now quite small (2 relatively active and 2 less active) while we have to maintain nearly 20 repos. I don't like insisting this really, but even I myself is not dedicated to oslo (Actually I'm not dedicated to even OpenStack...) but have had spent enormous time to deal with the oslo (and a few other dependencies) release works recently, to settle things down better. We can do further better, for sure, but I can't guarantee that I spend more effort like attending every single meeting of every project, checking every single line of code of every project to access any single change in oslo and so on, to address these problems only by oslo side. On 2/29/24 01:53, Thomas Goirand wrote:
On 2/28/24 09:45, Tony Breeds wrote:
Hi there, Happy to approve this as an FFE. Although if we can get the release out in the next few days. It'll just be a last minute release rather and FFE :)
Hi there!
Well technically, the non-client libs like Oslo were supposed to be released last week according to the schedule, which is why I (and probably others) began packaging them.
I'm not against a FFE if needed. Though this really *IS* a FFE, and not a "last minute release" as you worded.
Please do remember that any artifact upgrade *after* the planned schedule means double work for package maintainers (and everyone else downstream), which is why we try to follow the schedule, have freeze time, and have FFE when needed.
Cheers,
Thomas Goirand (zigo)
On 2/29/24 02:36, Takashi Kajinami wrote:
I've received similar feedback in a few other places. This is becoming off-topic from the original FEE discussion but probably it's worth discussing now to avoid the same confusion in the future.
The main factor here is that we create releases at the freeze timing, and then start testing the releases AFTER the freeze, when requirement bump is proposed. This means that any problems found after the release immediately become exceptions. Because of oslo's nature, it's quite difficult to catch all problems in oslo side (we can't run all tests from all projects to gate any change). If we more strictly aim non-client lib freeze then we may need to change some of our workflows here 1. Create the final releases some time BEFORE the freeze 2. Each project adds CI jobs with oslo master to catch problems early 3. Send out email for requirement CI failure to get more attention from project side
Probably having 2. as a non-voting job in each project is the most easily actionable way forward. On 2/29/24 02:36, Takashi Kajinami wrote:
Another factor I'd like to raise is the negligence to deprecation. There are multiple functionalities in oslo which were deprecated some time ago, but literally every time we attempt to remove these, we face the situation where these really old items are still used in some of the projects, with noisy warning ignored for years. The recent situation with sqlalchemy-migrate and sql-a is a clear example I'd say. I'd like to take this time to ask all to pay some more attentions to these ...
I can't agree more (even though the SQLA 2.x fixes were not trivial to write...). Some times ago, we had also some Python language deprecations that were ignored. I'm thinking namely for example about the collection -> collection.abc transition, but that's not the only one. Then guess who's patching when the feature is removed? An example of things that need to be fixed *now*: we currently have a number of datetime.utcnow() calls in Keystone, for example, that have to be removed ASAP. After this summer, Python 3.13 will be released, and then Keystone will fail hard if not fixed (the current workaround is to set warning as ignore instead of failing). This must be fixed at least for Dalmatian, but preferably before, and backported to Caracal, if possible. Cheers, Thomas Goirand (zigo)
participants (3)
-
Takashi Kajinami
-
Thomas Goirand
-
Tony Breeds