Open Stack

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.

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

-- 
Thierry Carrez (ttx)