Open Stack

Thanks Stephen for working on this! If those patches get merged *and* 
nothing else is needed, then Option 1 seems to be the better solution.

Anyone aware of other place where a fix is needed, or have uncertainties 
about Option 1?

Thanks,

Előd


On 2022. 09. 06. 12:38, Stephen Finucane wrote:
> 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 ?
>>>
>