Open Stack

On Tue, 2022-09-06 at 11:22 +0100, Stephen Finucane wrote:
> 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].

Actually, the barbican change isn't working because it isn't needed: Barbican
(helpfully) doesn't rely on autocommit. If we can get those other 5 patches
merged + the placement patch from gibi, we should have no issues with oslo.db
12.1.0. They're not long-term fixes and more bandaid solutions but they'll tide
us over until these projects can rework their DB layers to be SQLAlchemy 2.0
compatible in Antelope.

Stephen

> 
> 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 ?
> > 
>