Re: [openstack-dev] oslo.db 1.2.1 release coming to fix stable/juno

2014-12-17 Thread Thomas Goirand
On 12/16/2014 04:21 AM, Doug Hellmann wrote:
 The issue with stable/juno jobs failing because of the difference in the
 SQLAlchemy requirements between the older applications and the newer
 oslo.db is being addressed with a new release of the 1.2.x series. We 
 will then cap the requirements for stable/juno to 1.2.1. We decided we
 did not need to raise the minimum version of oslo.db allowed in kilo,
 because the old versions of the library do work, if they are installed
 from packages and not through setuptools.
 
 Jeremy created a feature/1.2 branch for us, and I have 2 patches up
 [1][2] to apply the requirements fix. The change to the oslo.db version
 in stable/juno is [3].
 
 After the changes in oslo.db merge, I will tag 1.2.1.
 
 Doug
 
 [1] https://review.openstack.org/#/c/141893/
 [2] https://review.openstack.org/#/c/141894/
 [3] https://review.openstack.org/#/c/141896/

Doug,

I'm not sure I get it. Is this related to newer versions of SQLAlchemy?
If so, then from my package maintainer point of view, keeping an older
version of SQLA (eg: 0.9.8) and oslo.db 1.0.2 for Juno is ok, right?

Will Kilo require a newer version of SQLA?

Cheers,

Thomas


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] oslo.db 1.2.1 release coming to fix stable/juno

2014-12-17 Thread Jeremy Stanley
On 2014-12-17 22:02:26 +0800 (+0800), Thomas Goirand wrote:
 I'm not sure I get it. Is this related to newer versions of SQLAlchemy?

It's related to how Setuptools 8 failed to parse our requirements
line for SQLAlchemy because it contained multiple version ranges.
That was fixed by converting it to a single range with a list of
excluded versions instead, but we still needed to backport that
requirements.txt entry to a version of oslo.db for stable/juno.

 If so, then from my package maintainer point of view, keeping an older
 version of SQLA (eg: 0.9.8) and oslo.db 1.0.2 for Juno is ok, right?

In the end we wound up with a 1.0.3 release of oslo.db and pinned
stable/juno requirements to oslo.db1.1 rather than the open-ended
maximum it previously had (which was including 1.1.x and 1.2.x
versions).

 Will Kilo require a newer version of SQLA?

In this case older SQLAlchemy is 0.8.x (we're listing supported
0.8.x and 0.9.x versions for stable/juno still), while Kilo may
release with only a supported range of SQLAlchemy 0.9.x versions.
-- 
Jeremy Stanley

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] oslo.db 1.2.1 release coming to fix stable/juno

2014-12-16 Thread Doug Hellmann

On Dec 15, 2014, at 5:58 PM, Doug Hellmann d...@doughellmann.com wrote:

 
 On Dec 15, 2014, at 3:21 PM, Doug Hellmann d...@doughellmann.com wrote:
 
 The issue with stable/juno jobs failing because of the difference in the 
 SQLAlchemy requirements between the older applications and the newer oslo.db 
 is being addressed with a new release of the 1.2.x series. We will then cap 
 the requirements for stable/juno to 1.2.1. We decided we did not need to 
 raise the minimum version of oslo.db allowed in kilo, because the old 
 versions of the library do work, if they are installed from packages and not 
 through setuptools.
 
 Jeremy created a feature/1.2 branch for us, and I have 2 patches up [1][2] 
 to apply the requirements fix. The change to the oslo.db version in 
 stable/juno is [3].
 
 After the changes in oslo.db merge, I will tag 1.2.1.
 
 After spending several hours exploring a bunch of options to make this 
 actually work, some of which require making changes to test job definitions, 
 grenade, or other long-term changes, I’m proposing a new approach:
 
 1. Undo the change in master that broke the compatibility with versions of 
 SQLAlchemy by making master match juno: https://review.openstack.org/141927
 2. Update oslo.db after ^^ lands.
 3. Tag oslo.db 1.4.0 with a set of requirements compatible with Juno.
 4. Change the requirements in stable/juno to skip oslo.db 1.1, 1.2, and 1.3.
 
 I’ll proceed with that plan tomorrow morning (~15 hours from now) unless 
 someone points out why that won’t work in the mean time.

I just reset a few approved patches that were not going to land because of this 
issue to kick them out of the gate to expedite landing part of the fix. I did 
this by modifying their commit messages. I tried to limit the changes to simple 
cosmetic tweaks, so if you see a weird change to one of your patches that’s 
probably why.

 
 Doug
 
 
 Doug
 
 [1] https://review.openstack.org/#/c/141893/
 [2] https://review.openstack.org/#/c/141894/
 [3] https://review.openstack.org/#/c/141896/
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] oslo.db 1.2.1 release coming to fix stable/juno

2014-12-16 Thread Doug Hellmann

On Dec 16, 2014, at 8:15 AM, Doug Hellmann d...@doughellmann.com wrote:

 
 On Dec 15, 2014, at 5:58 PM, Doug Hellmann d...@doughellmann.com wrote:
 
 
 On Dec 15, 2014, at 3:21 PM, Doug Hellmann d...@doughellmann.com wrote:
 
 The issue with stable/juno jobs failing because of the difference in the 
 SQLAlchemy requirements between the older applications and the newer 
 oslo.db is being addressed with a new release of the 1.2.x series. We will 
 then cap the requirements for stable/juno to 1.2.1. We decided we did not 
 need to raise the minimum version of oslo.db allowed in kilo, because the 
 old versions of the library do work, if they are installed from packages 
 and not through setuptools.
 
 Jeremy created a feature/1.2 branch for us, and I have 2 patches up [1][2] 
 to apply the requirements fix. The change to the oslo.db version in 
 stable/juno is [3].
 
 After the changes in oslo.db merge, I will tag 1.2.1.
 
 After spending several hours exploring a bunch of options to make this 
 actually work, some of which require making changes to test job definitions, 
 grenade, or other long-term changes, I’m proposing a new approach:
 
 1. Undo the change in master that broke the compatibility with versions of 
 SQLAlchemy by making master match juno: https://review.openstack.org/141927
 2. Update oslo.db after ^^ lands.
 3. Tag oslo.db 1.4.0 with a set of requirements compatible with Juno.
 4. Change the requirements in stable/juno to skip oslo.db 1.1, 1.2, and 1.3.
 
 I’ll proceed with that plan tomorrow morning (~15 hours from now) unless 
 someone points out why that won’t work in the mean time.
 
 I just reset a few approved patches that were not going to land because of 
 this issue to kick them out of the gate to expedite landing part of the fix. 
 I did this by modifying their commit messages. I tried to limit the changes 
 to simple cosmetic tweaks, so if you see a weird change to one of your 
 patches that’s probably why.

That solution evolved into a third approach, which has taken most of the day to 
land.

We now have an oslo.db 1.0.3 with SQLAlchemy requirements that work with 
setuptools 8. stable/juno is currently capped to oslo.db1.0.0,1.3 but another 
change to move the cap down to 1.1 is in the queue right now [1]. This is a 
lower cap than the last tests we were running, but it has the benefit of 
providing a version of oslo.db that does not introduce any other requirements 
changes in stable/juno as 1.2.1 would have. More details are available in the 
etherpad we used for notes today [2], and of course please post here if you 
have questions.

Doug

[1] https://review.openstack.org/#/c/142180/2
[2] https://etherpad.openstack.org/p/cloL2FzTRd

 
 
 Doug
 
 
 Doug
 
 [1] https://review.openstack.org/#/c/141893/
 [2] https://review.openstack.org/#/c/141894/
 [3] https://review.openstack.org/#/c/141896/
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] oslo.db 1.2.1 release coming to fix stable/juno

2014-12-15 Thread Doug Hellmann

On Dec 15, 2014, at 3:21 PM, Doug Hellmann d...@doughellmann.com wrote:

 The issue with stable/juno jobs failing because of the difference in the 
 SQLAlchemy requirements between the older applications and the newer oslo.db 
 is being addressed with a new release of the 1.2.x series. We will then cap 
 the requirements for stable/juno to 1.2.1. We decided we did not need to 
 raise the minimum version of oslo.db allowed in kilo, because the old 
 versions of the library do work, if they are installed from packages and not 
 through setuptools.
 
 Jeremy created a feature/1.2 branch for us, and I have 2 patches up [1][2] to 
 apply the requirements fix. The change to the oslo.db version in stable/juno 
 is [3].
 
 After the changes in oslo.db merge, I will tag 1.2.1.

After spending several hours exploring a bunch of options to make this actually 
work, some of which require making changes to test job definitions, grenade, or 
other long-term changes, I’m proposing a new approach:

1. Undo the change in master that broke the compatibility with versions of 
SQLAlchemy by making master match juno: https://review.openstack.org/141927
2. Update oslo.db after ^^ lands.
3. Tag oslo.db 1.4.0 with a set of requirements compatible with Juno.
4. Change the requirements in stable/juno to skip oslo.db 1.1, 1.2, and 1.3.

I’ll proceed with that plan tomorrow morning (~15 hours from now) unless 
someone points out why that won’t work in the mean time.

Doug

 
 Doug
 
 [1] https://review.openstack.org/#/c/141893/
 [2] https://review.openstack.org/#/c/141894/
 [3] https://review.openstack.org/#/c/141896/
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev