Open Stack

Hi,
Revert sounds the rational solution, even if it is a hard decision as a lot
of people/projects already put a lot of efforts to work on it.
As I see if we revert it now and rever the revert and do a quick release of
oslo.db in 2023.1 (aka Antelope) we can force projects to act,
and give time to TC to force-approve it for understaffed projects.

Lajos

Slawek Kaplonski <skaplons at redhat.com> ezt írta (időpont: 2022. szept. 6.,
K, 9:35):

> Hi,
>
> Dnia poniedziałek, 5 września 2022 18:14:27 CEST Stephen Finucane pisze:
> > On Mon, 2022-09-05 at 16:19 +0200, Előd Illés wrote:
> > > Hi,
> > > With the latest oslo.db 12.1.0 release it seems multiple repositories
> are
> > > broken (see the corresponding requirements patch [1] for details, and
> probably
> > > there are more, that are not tested within requirements repository).
> The patch
> > > that introduces the break [2] "is necessary for oslo.db and openstack
> > > applications in general to be able to run on SQLAlchemy 2.0" according
> to
> > > patch author.
> > > Since we are after the 3rd milestone of Zed, we have very limited time
> to
> > > figure out what to do. The 2 options are:
> > >
> > > 1) fix every broken repository to work with oslo.db 12.1.0
> > >      as far as we know this is quite impossible as for some
> repositories the
> > > already existing fixes took almost a cycle to be implemented and there
> are
> > > still undiscovered bugs around this. (we don't know if this is really
> true, or
> > > probably there are cases where it's easy to fix)
> >
> > I don't think this is True. To fully prepare for SQLAlchemy 2.0 you
> would need
> > to do this work, yes, however the issue here is that oslo.db no longer
> > *defaults* to enabling one of the SQLAlchemy features that's being
> removed in
> > 2.0, autocommit, and not that it no longer supports it. There's nothing
> to stop
> > the affected projects from manually enabling autocommit behavior and to
> prove
> > this I just put together a patch for aodh to do just that [1]. Manually
> enabling
> > this feature would be my preferred approach since it means we're kicking
> a
> > slightly smaller can down the road and we'll have a better understanding
> of the
> > projects that still need to do work for SQLAlchemy 2.0, but I don't know
> how
> > likely it is that we can land all of these in the next week.
> >
> > > 2) revert the breaking change [2] and do another release in oslo.db now
> > > without it (and add it back after Zed release & release oslo.db with
> it as
> > > soon as possible in Antelope cycle)
> > >      as far as we understand this does not cause any issue for those
> who
> > > already adapted to oslo.db 12.1.0, so this should not be painful
> >
> > This is all true, but it doesn't actually fix anything and delays the
> necessary
> > work to get us moving in the right direction. I've been harping on about
> the
> > fact that SQLAlchemy 2.0 is coming and will affect many projects for
> over a year
> > now [2] so perhaps a small but firm nudge like this would be beneficial
> and get
> > things rolling moving into Antelope?
>
> I would vote for reverting it now as we are close to the Zed release
> deadline and then reverting this revert very early in the Antelope cycle to
> give projects chance to adopt to the change or enable autocommit feature on
> their own and start slower adoption later.
>
> >
> > > Based on the above Release team is opting toward the 2nd option.
> > > Please let us know your opinion!
> > > [1] https://review.opendev.org/c/openstack/requirements/+/855153/
> > >  [2] https://review.opendev.org/c/openstack/oslo.db/+/804775
> > > Thanks,
> > >
> > >  Előd
> >
> > Cheers,
> > Stephen
> >
> > [1] https://review.opendev.org/c/openstack/aodh/+/855962
> > [2]
> https://lists.openstack.org/pipermail/openstack-discuss/2021-August/024122.html
> >
> >
> >
>
>
> --
> Slawek Kaplonski
> Principal Software Engineer
> Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20220906/1f21d11a/attachment-0001.htm>