<div dir="ltr"><div>On Fri, 15 Sept 2023 at 13:29, Stephen Finucane <<a href="mailto:stephenfin@redhat.com">stephenfin@redhat.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On Fri, 2023-09-15 at 13:07 +0200, Thomas Goirand wrote:<br>
> On 9/13/23 15:39, Stephen Finucane wrote:<br>
> > On Wed, 2023-09-13 at 09:21 +0200, Thomas Goirand wrote:<br>
> > > Hi,<br>
> > > <br>
> > > As you may know, and to my great frustration, I'm not the maintainer of<br>
> > > SQLAlchemy in Debian, even though OpenStack is the biggest consumer of<br>
> > > it. The current maintainer insists that he wants to upload SQLA 2.x in<br>
> > > Unstable, potentially breaking all of OpenStack.<br>
> > > <br>
> > > At the present moment, if I understand correctly, we're not there yet,<br>
> > > and Bobcat doesn't have such a support. It would be ok for me, *IF*<br>
> > > there are patches available on master, that I could backport to Bobcat<br>
> > > and maintain in the debian/patches folder of each project. However, the<br>
> > > biggest current annoyance, is that I have no idea where we are at. Are<br>
> > > we close to such a support? Is there a list of patches to apply on top<br>
> > > of Bobcat that is maintained somewhere?<br>
> > > <br>
> > > Please enlighten me... :)<br>
> > <br>
> > I think you figured this out on IRC this morning, but the vast majority (though<br>
> > not all) of the patches are available at the sqlalchemy-20 topic in Gerrit [1].<br>
> > I've been working on this for almost 2 years now and have most of the core<br>
> > projects well on their way but not everything is complete, as you'll tell from<br>
> > that list. I have a canary patch [2] that I've been using to spot missing<br>
> > services. I plan to pick up the Manila work again early in C, but could do with<br>
> > help removing the use of autocommit in Heat and the weird test failures I'm<br>
> > seeing in Cinder [3]. We also need reviews of the Masakri series (Is that<br>
> > project dead? I can't tell). Once those are addressed, I _think_ we might be<br>
> > done but who knows what else we'll find...<br>
> > <br>
> > Cheers,<br>
> > Stephen<br>
> > <br>
> > [1] <a href="https://review.opendev.org/q/topic:sqlalchemy-20+is:open" rel="noreferrer" target="_blank">https://review.opendev.org/q/topic:sqlalchemy-20+is:open</a><br>
> > [2] <a href="https://review.opendev.org/c/openstack/requirements/+/879743" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/requirements/+/879743</a><br>
> > [3] <a href="https://review.opendev.org/q/topic:sqlalchemy-20+is:open+project:openstack/cinder" rel="noreferrer" target="_blank">https://review.opendev.org/q/topic:sqlalchemy-20+is:open+project:openstack/cinder</a><br>
> <br>
> Thanks for your work, really!<br>
> And thanks for the details above.<br>
> <br>
> Now, not sure how much this is related, but I've seen that the new <br>
> oslo.db 14.0.0 breaks:<br>
> - freezer-api<br>
> - trove<br>
> - cloudkitty<br>
> - watcher<br>
> <br>
> Is there any plan to fix oslo.db, or the above projects? Maybe revert <br>
> some commits in oslo.db? Can someone explain to me what's going on for <br>
> this as well?<br>
<br>
oslo.db has intentionally *not* been bumped to >= 13.0.0 in upper-constraints<br>
because it introduces many breaking changes that are not compatible with<br>
SQLAlchemy 2.x. Conversely, oslo.db < 13.0.0 is simply not compatible with<br>
SQLAlchemy >= 2.x. As such, we can't bump oslo.db until the various projects<br>
have been fixed which is the same as what we're seeing with SQLAlchemy 2.x.<br>
<br>
Fortunately projects that adopt to I have been pushing patches to various<br>
projects that add a "tips" job for testing main/master branches of SQLAlchemy,<br>
Alembic, and oslo.db, e.g. [1][2][3][4]. The Neutron folks were well ahead of<br>
the curve as usual and also have their own (which is where I got the idea from).<br>
The projects you mention above could do with an equivalent job and my guess is<br>
that the process of getting there will highlight quite a bit of work that they<br>
need to do. They need to start at that asap (and tbh really should have started<br>
at it a long time ago as they've had over 2 years of a warning [5]).<br>
<br>
Cheers,<br>
Stephen<br>
<br>
[1] <a href="https://review.opendev.org/c/openstack/barbican/+/888308" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/barbican/+/888308</a><br>
[2] <a href="https://review.opendev.org/c/openstack/placement/+/886229" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/placement/+/886229</a><br>
[3] <a href="https://review.opendev.org/c/openstack/cinder/+/886152" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/cinder/+/886152</a><br>
[4] <a href="https://review.opendev.org/c/openstack/glance/+/889066" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/glance/+/889066</a><br>
[5] <a href="https://lists.openstack.org/pipermail/openstack-discuss/2021-August/024122.html" rel="noreferrer" target="_blank">https://lists.openstack.org/pipermail/openstack-discuss/2021-August/024122.html</a><br>
<br>
> <br>
> Cheers,<br>
> <br>
> Thomas Goirand (zigo)<br>
> <br></blockquote><div><br></div><div>Thank you for highlighting cloudkitty. I added it as a discussion item for our meeting next week.</div><div><br></div><div>Cheers,</div><div>Pierre </div></div></div>