Open Stack

On 6/9/15 9:26 AM, Thomas Goirand wrote:
> Hi,
>
> The python-sqlalchemy package has been uploaded to Debian Experimental,
> and is about to be uploaded to Debian Unstable. So I wonder what's the
> state of the project regarding upgrading SQLA.
>
> Maybe Mike can tell what kind of issue we may run into? How much work
> will it be to switch to SQLA 1.0.x for Liberty? Is it possible to be
> compatible with both 9.x and 1.x (which would be the best way forward)?

The short answer is that there are no supported use cases that have been 
intentionally changed in any backwards incompatible way in 1.0 and all 
Openstack code should be able to accommodate from 0.9.x -> 1.0.x without 
any change.

I run SQLAlchemy's master against a small subset of Openstack tests 
continuously, including Nova DB API, Keystone, all of oslo.db and 
Neutron's migration tests, and there was nothing that needed changing as 
we went along.   I've also run devstack against SQLAlchemy 1.0 without 
problems though I don't have a lot of openstack-user-fu so I didn't 
stress test it too much at that level.

It's my expectation that nothing in Openstack should have to change to 
work with SQLAlchemy 1.0 - the kinds of things that change tend to be 
subtle things related to odd use cases and newer features, usually along 
the lines of applications that may have been relying upon some behavior 
that was undefined, that then changes it's behavior in some way.

An example is that we had a user who was running a query of the form 
"session.query(SomeObject).with_parent(SomeParent(id=None))", e.g. 
trying to find objects that *didn't* have a parent by using a transient 
"Parent" with "id=None" - totally unexpected way of doing that, and it 
wasn't even working for that user as it came up with an "= NULL" 
comparison that isn't even right, *but* when SQLA 1.0 came around it 
started leaking an internal symbol into the query, and *then* it became 
noticeable.  That's the kind of thing that "breaks" with new SQLAlchemy 
versions these days.   We had a lot of those this time around, and the 
vast majority of them were logged as regressions which were fixed and 
added to testing.   You can see those by browsing versions 1.0.1 -> 
1.0.5 at http://docs.sqlalchemy.org/en/rel_1_0/changelog/changelog_10.html.

We never intentionally make *any* backwards incompatible change in just 
one major version without warnings being emitted in the previous 
version, and the warnings usually involve urging the user to set a flag 
to "use the old way" if they're going to upgrade; that is, we at least 
always try to add flags to keep an old behavior in place if at all 
possible.   I've not seen anything in Openstack that would be sensitive 
to this kind of issue for 1.0.

So for Openstack, we would mostly worry about code that is doing things 
oddly in some unexpected way, however all the Openstack code I've seen 
tends to be very ORM centric and uses the ORM very conservatively so I 
don't anticipate any problems.   I would note that some silently-/ 
quasi- failing use cases for query.update() and query.delete()  now 
raise exceptions in 1.0.   They both emit warnings in 0.9 but I just 
checked and apparently one of these warnings is only in the as-yet 
unreleased 0.9.10.   I've just added an extra migration note for one of 
these which appeared to be missing in the migration document (as of this 
writing it should be up on RTD within an hour).

That said, the document which tries to capture everything that might be 
surprising is at 
http://docs.sqlalchemy.org/en/rel_1_0/changelog/migration_10.html.


>
> Cheers,
>
> Thomas Goirand (zigo)
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev