settingsLogin | Registersettings

[openstack-dev] [all] Switching to SQLAlchemy 1.0.x

0 votes

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)?

Cheers,

Thomas Goirand (zigo)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Jun 9, 2015 in openstack-dev by Thomas_Goirand (18,640 points)   3 10 16

10 Responses

0 votes

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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 9, 2015 by Mike_Bayer (15,260 points)   1 5 6
0 votes

On 6/9/15 1:08 PM, Mike Bayer wrote:

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.

here are those:

http://sqlalchemy.readthedocs.org/en/rel_1_0/changelog/migration_10.html#query-update-query-delete-raises-if-used-with-join-select-from-from-self
http://sqlalchemy.readthedocs.org/en/rel_1_0/changelog/migration_10.html#query-update-with-synchronize-session-evaluate-raises-on-multi-table-update

Cheers,

Thomas Goirand (zigo)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 9, 2015 by Mike_Bayer (15,260 points)   1 5 6
0 votes

On Tue, Jun 9, 2015 at 8:08 PM, Mike Bayer mbayer@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@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 9, 2015 by Joe_Gordon (24,620 points)   2 5 8
0 votes

Hi Mike,

Thanks a lot for your quick reply which is very useful to me.

On 06/09/2015 07:08 PM, Mike Bayer 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.

Ah, super cool!

I saw that this passed all tests:
https://review.openstack.org/#/c/189847/

Could we get it approved?

Mike


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 10, 2015 by Thomas_Goirand (18,640 points)   3 10 16
0 votes

On 6/10/15 3:26 AM, Thomas Goirand wrote:
Hi Mike,

Thanks a lot for your quick reply which is very useful to me.

On 06/09/2015 07:08 PM, Mike Bayer 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.
Ah, super cool!

I saw that this passed all tests:
https://review.openstack.org/#/c/189847/

whew! :)

Could we get it approved?

Mike


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 10, 2015 by Mike_Bayer (15,260 points)   1 5 6
0 votes

On 06/10/2015 04:52 PM, Mike Bayer wrote:

On 6/10/15 3:26 AM, Thomas Goirand wrote:

Hi Mike,

Thanks a lot for your quick reply which is very useful to me.

On 06/09/2015 07:08 PM, Mike Bayer 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.
Ah, super cool!

I saw that this passed all tests:
https://review.openstack.org/#/c/189847/

whew! :)

Do you know why it fails with Kilo?

https://review.openstack.org/#/c/190062/

Thomas


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 10, 2015 by Thomas_Goirand (18,640 points)   3 10 16
0 votes

On 6/10/15 5:18 PM, Thomas Goirand wrote:
On 06/10/2015 04:52 PM, Mike Bayer wrote:

whew! :)
Do you know why it fails with Kilo?

https://review.openstack.org/#/c/190062/

I noticed this, I don't know very well how the requirements get
distributed around but seems like it is not happening here:

http://logs.openstack.org/62/190062/2/check/check-grenade-dsvm/d4597a4/logs/grenade.sh.txt.gz

2015-06-10 09:11:16.933

| Traceback (most recent call last): 2015-06-10 09:11:16.933

| File "/usr/local/bin/keystone-manage", line 4, in 2015-06-10
09:11:16.933

| import('pkg_resources').require('keystone==2015.1.1.dev5')
2015-06-10 09:11:16.934

| File
"/usr/local/lib/python2.7/dist-packages/pkg_resources/init.py", line
3084, in 2015-06-10 09:11:16.934

| @callaside 2015-06-10 09:11:16.934

| File
"/usr/local/lib/python2.7/dist-packages/pkgresources/init.py", line
3070, in _call
aside 2015-06-10 09:11:16.934

| f(*args, **kwargs) 2015-06-10 09:11:16.934

| File
"/usr/local/lib/python2.7/dist-packages/pkgresources/init.py", line
3097, in _initialize
masterworkingset 2015-06-10 09:11:16.935

| workingset = WorkingSet.build_master() 2015-06-10 09:11:16.935

| File
"/usr/local/lib/python2.7/dist-packages/pkgresources/init.py", line
653, in _build
master 2015-06-10 09:11:16.935

| return cls.buildfrom_requirements(requires) 2015-06-10
09:11:16.935

| File
"/usr/local/lib/python2.7/dist-packages/pkgresources/init.py", line
666, in _build
from_requirements 2015-06-10 09:11:16.935

| dists = ws.resolve(reqs, Environment()) 2015-06-10 09:11:16.935

| File
"/usr/local/lib/python2.7/dist-packages/pkg_resources/init.py", line
844, in resolve 2015-06-10 09:11:16.935

| raise VersionConflict(dist, req).withcontext(dependentreq)
2015-06-10 09:11:16.935

| pkg_resources.ContextualVersionConflict: (SQLAlchemy 1.0.5
(/usr/local/lib/python2.7/dist-packages),
Requirement.parse('SQLAlchemy<=0.9.99,>=0.9.7'), set(['oslo.db']))
2015-06-10 09:11:16.942

| + die 89 'DB sync error' 2015-06-10 09:11:16.942

| + local exitcode=1 2015-06-10 09:11:16.942

| [Call Trace] 2015-06-10 09:11:16.942

| /opt/stack/new/grenade/projects/10_keystone/upgrade.sh:89:die
2015-06-10 09:11:16.944

| [ERROR] /opt/stack/new/grenade/projects/10_keystone/upgrade.sh:89 DB
sync error 2015-06-10 09:11:17.946

| 1 die /opt/stack/new/devstack/functions-common 2015-06-10 09:11:17.946

| + die 68 'Failure in
/opt/stack/new/grenade/projects/10_keystone/upgrade.sh' 2015-06-10
09:11:17.946

| + local exitcode=1 2015-06-10 09:11:17.946

| [Call Trace] 2015-06-10 09:11:17.946

| ./grenade.sh:274:upgrade_service 2015-06-10 09:11:17.946

| /opt/stack/new/grenade/inc/upgrade:68:die 2015-06-10 09:11:17.948

| [ERROR] /opt/stack/new/grenade/inc/upgrade:68 Failure in
/opt/stack/new/grenade/projects/10_keystone/upgrade.sh 2015-06-10
09:11:18.951

| 1 die /opt/stack/new/devstack/functions-common

Thomas


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 10, 2015 by Mike_Bayer (15,260 points)   1 5 6
0 votes

I think it would first require a version of oslo.db to be released inside
stable/kilo's bounds that uncapped SQLAlchemy first since the requirement
in the version of oslo.db installed is what you see here
http://logs.openstack.org/62/190062/2/check/check-tempest-dsvm-neutron-full
/f6baf92/logs/devstacklog.txt.gz#_2015-06-10_08_55_25_992

Seems like a bit of a chicken-and-egg problem.

On 6/10/15, 16:23, "Mike Bayer" mbayer@redhat.com wrote:

On 6/10/15 5:18 PM, Thomas Goirand wrote:

On 06/10/2015 04:52 PM, Mike Bayer wrote:
whew! :)

Do you know why it fails with Kilo?

https://review.openstack.org/#/c/190062/

I noticed this, I don't know very well how the requirements get
distributed around but seems like it is not happening here:

http://logs.openstack.org/62/190062/2/check/check-grenade-dsvm/d4597a4/log
s/grenade.sh.txt.gz

2015-06-10 09:11:16.933
gs/grenade.sh.txt.gz#_2015-06-10_09_11_16_933> | Traceback (most recent
call last):
2015-06-10 09:11:16.933
gs/grenade.sh.txt.gz#_2015-06-10_09_11_16_933> | File
"/usr/local/bin/keystone-manage", line 4, in
2015-06-10 09:11:16.933
gs/grenade.sh.txt.gz#_2015-06-10_09_11_16_933> |
import('pkgresources').require('keystone==2015.1.1.dev5')
2015-06-10 09:11:16.934
gs/grenade.sh.txt.gz#_2015-06-10_09_11_16_934> | File
"/usr/local/lib/python2.7/dist-packages/pkg
resources/init.py", line
3084, in
2015-06-10 09:11:16.934
gs/grenade.sh.txt.gz#_2015-06-10_09_11_16_934> | @callaside
2015-06-10 09:11:16.934
gs/grenade.sh.txt.gz#_2015-06-10_09_11_16_934> | File
"/usr/local/lib/python2.7/dist-packages/pkgresources/init.py", line
3070, in _call
aside
2015-06-10 09:11:16.934
gs/grenade.sh.txt.gz#_2015-06-10_09_11_16_934> | f(*args, **kwargs)
2015-06-10 09:11:16.934
gs/grenade.sh.txt.gz#_2015-06-10_09_11_16_934> | File
"/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line
3097, in _initialize_master_working_set
2015-06-10 09:11:16.935
gs/grenade.sh.txt.gz#_2015-06-10_09_11_16_935> | working_set =
WorkingSet._build_master()
2015-06-10 09:11:16.935
gs/grenade.sh.txt.gz#_2015-06-10_09_11_16_935> | File
"/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line
653, in _build_master
2015-06-10 09:11:16.935
gs/grenade.sh.txt.gz#_2015-06-10_09_11_16_935> | return
cls._build_from_requirements(__requires__)
2015-06-10 09:11:16.935
gs/grenade.sh.txt.gz#_2015-06-10_09_11_16_935> | File
"/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line
666, in _build_from_requirements
2015-06-10 09:11:16.935
gs/grenade.sh.txt.gz#_2015-06-10_09_11_16_935> | dists =
ws.resolve(reqs, Environment())
2015-06-10 09:11:16.935
gs/grenade.sh.txt.gz#_2015-06-10_09_11_16_935> | File
"/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line
844, in resolve
2015-06-10 09:11:16.935
gs/grenade.sh.txt.gz#_2015-06-10_09_11_16_935> | raise
VersionConflict(dist, req).with_context(dependent_req)
2015-06-10 09:11:16.935
gs/grenade.sh.txt.gz#_2015-06-10_09_11_16_935> |
pkg_resources.ContextualVersionConflict: (SQLAlchemy 1.0.5
(/usr/local/lib/python2.7/dist-packages),
Requirement.parse('SQLAlchemy<=0.9.99,>=0.9.7'), set(['oslo.db']))
2015-06-10 09:11:16.942
gs/grenade.sh.txt.gz#_2015-06-10_09_11_16_942> | + die 89 'DB sync error'
2015-06-10 09:11:16.942
gs/grenade.sh.txt.gz#_2015-06-10_09_11_16_942> | + local exitcode=1
2015-06-10 09:11:16.942
gs/grenade.sh.txt.gz#_2015-06-10_09_11_16_942> | [Call Trace]
2015-06-10 09:11:16.942
gs/grenade.sh.txt.gz#_2015-06-10_09_11_16_942> |
/opt/stack/new/grenade/projects/10_keystone/upgrade.sh:89:die
2015-06-10 09:11:16.944
gs/grenade.sh.txt.gz#_2015-06-10_09_11_16_944> | [ERROR]
/opt/stack/new/grenade/projects/10_keystone/upgrade.sh:89 DB sync error
2015-06-10 09:11:17.946
gs/grenade.sh.txt.gz#_2015-06-10_09_11_17_946> | 1 die
/opt/stack/new/devstack/functions-common
2015-06-10 09:11:17.946
gs/grenade.sh.txt.gz#_2015-06-10_09_11_17_946> | + die 68 'Failure in
/opt/stack/new/grenade/projects/10_keystone/upgrade.sh'
2015-06-10 09:11:17.946
gs/grenade.sh.txt.gz#_2015-06-10_09_11_17_946> | + local exitcode=1
2015-06-10 09:11:17.946
gs/grenade.sh.txt.gz#_2015-06-10_09_11_17_946> | [Call Trace]
2015-06-10 09:11:17.946
gs/grenade.sh.txt.gz#_2015-06-10_09_11_17_946> |
./grenade.sh:274:upgrade_service
2015-06-10 09:11:17.946
gs/grenade.sh.txt.gz#_2015-06-10_09_11_17_946> |
/opt/stack/new/grenade/inc/upgrade:68:die
2015-06-10 09:11:17.948
gs/grenade.sh.txt.gz#_2015-06-10_09_11_17_948> | [ERROR]
/opt/stack/new/grenade/inc/upgrade:68 Failure in
/opt/stack/new/grenade/projects/10_keystone/upgrade.sh
2015-06-10 09:11:18.951
gs/grenade.sh.txt.gz#_2015-06-10_09_11_18_951> | 1 die
/opt/stack/new/devstack/functions-common

Thomas


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribehttp://lists.
openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 10, 2015 by Ian_Cordasco (5,340 points)   1 3 4
0 votes

On 06/10/2015 11:23 PM, Mike Bayer wrote:

On 6/10/15 5:18 PM, Thomas Goirand wrote:

On 06/10/2015 04:52 PM, Mike Bayer wrote:

whew! :)
Do you know why it fails with Kilo?

https://review.openstack.org/#/c/190062/

I noticed this, I don't know very well how the requirements get
distributed around but seems like it is not happening here:

http://logs.openstack.org/62/190062/2/check/check-grenade-dsvm/d4597a4/logs/grenade.sh.txt.gz

pkg_resources.ContextualVersionConflict: (SQLAlchemy 1.0.5 (/usr/local/lib/python2.7/dist-packages), Requirement.parse('SQLAlchemy<=0.9.99,>=0.9.7'), set(['oslo.db']))

Yeah, so we are bitten by over-restricting requirements in oslo.db.
Nothing which can't be fixed, IMO.

Would it be ok to first fix oslo.db, and then unrestrict in
global-requirements.txt? Is this the way to go?

I really would love to see this fixed in the Kilo branch, because no
mater what, SQLAlchemy 1.0.x will be uploaded to Sid, and I'd prefer
that it doesn't just break hard Kilo which is there...

Cheers,

Thomas Goirand (zigo)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 11, 2015 by Thomas_Goirand (18,640 points)   3 10 16
0 votes

On 06/12/2015 12:34 AM, Thomas Goirand wrote:
On 06/10/2015 11:23 PM, Mike Bayer wrote:

On 6/10/15 5:18 PM, Thomas Goirand wrote:

On 06/10/2015 04:52 PM, Mike Bayer wrote:

whew! :)
Do you know why it fails with Kilo?

https://review.openstack.org/#/c/190062/

I noticed this, I don't know very well how the requirements get
distributed around but seems like it is not happening here:

http://logs.openstack.org/62/190062/2/check/check-grenade-dsvm/d4597a4/logs/grenade.sh.txt.gz

pkg_resources.ContextualVersionConflict: (SQLAlchemy 1.0.5 (/usr/local/lib/python2.7/dist-packages), Requirement.parse('SQLAlchemy<=0.9.99,>=0.9.7'), set(['oslo.db']))

Yeah, so we are bitten by over-restricting requirements in oslo.db.
Nothing which can't be fixed, IMO.

Would it be ok to first fix oslo.db, and then unrestrict in
global-requirements.txt? Is this the way to go?

I really would love to see this fixed in the Kilo branch, because no
mater what, SQLAlchemy 1.0.x will be uploaded to Sid, and I'd prefer
that it doesn't just break hard Kilo which is there...

Cheers,

Thomas Goirand (zigo)

FYI:

https://review.openstack.org/#/c/190848/

(I don't have the CI result as of writing...)

Thomas


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 11, 2015 by Thomas_Goirand (18,640 points)   3 10 16
...