Open Stack

On Tue, Jun 9, 2015 at 8:08 PM, Mike Bayer <mbayer at redhat.com> wrote:

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

Just posted a patch to test this out:  https://review.openstack.org/189847


>
> 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
>>
>
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150609/5e82b1af/attachment.html>