Open Stack

On Mon, 2022-09-05 at 19:00 +0200, Thierry Carrez wrote:
> Stephen Finucane wrote:
> > On Mon, 2022-09-05 at 16:19 +0200, Előd Illés wrote:
> > > [...] 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.
> 
> I agree this is the preferable option... and if we had a couple extra 
> weeks to make it happen I would pick it without hesitation...
> 
> Here I feel to make it happen in time for the Zed release we'll need to 
> get someone to post all the autocommit option patches and potentially 
> the TC stepping in to authorize the TaCT team to force-approve the ones 
> that would not get attention from their core teams in time.

I did those yesterday.

Aodh: https://review.opendev.org/c/openstack/aodh/+/855962
Designate: https://review.opendev.org/c/openstack/designate/+/855965
Manila: https://review.opendev.org/c/openstack/manila/+/855967
Ironic: https://review.opendev.org/c/openstack/ironic/+/855969
Heat: https://review.opendev.org/c/openstack/heat/+/855970
Barbican: https://review.opendev.org/c/openstack/barbican/+/855972

The barbican one isn't correct and I need to respin it. The rest are working as
expected though, as proven at [1].

Stephen

[1] https://review.opendev.org/c/openstack/requirements/+/855973/

> 
> > > 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 agree it's a step back without guarantee that things would go a lot 
> better in the Antelope redo... but it is a more controlled path.
> 
> I'd say we should see if we can get critical attention on this in the 
> next couple of days, and if not we can use option (2) as a plan B ?
>