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:
[...] 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
On Mon, 2022-09-05 at 16:19 +0200, Előd Illés wrote: 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 ?