Davanum Srinivas wrote:
On Mon, Apr 18, 2016 at 4:28 PM, Joshua Harlow<harlo...@fastmail.com> wrote:
Okie, the following reviews are up:
https://review.openstack.org/307461 (oslo.concurrency)
https://review.openstack.org/307463 (oslo.cache)
https://review.openstack.org/307464 (oslo.privsep)
https://review.openstack.org/307466 (oslo.middleware)
https://review.openstack.org/307467 (oslo.log)
https://review.openstack.org/307468 (oslo.db)
https://review.openstack.org/307469 (oslo.versionedobjects)
https://review.openstack.org/307470 (oslo.service)
https://review.openstack.org/307471 (oslo.reports)
Do note that the following have a dependency on babel but do not depend on
oslo.il8n:
tooz
oslo.context
oslo.serialization
debtcollector
Should we do anything about the above four?
Josh,
Babel is mainly for translations:
https://wiki.openstack.org/wiki/Translations
So we can remove them
-- Dims
Okie, sounds fine with me,
I hope there isn't any translation(s) in those four that people want/are
using, because its to my understanding that it will no longer exist if I
remove that dependency ;)
-Josh
Doug Hellmann wrote:
Excerpts from Davanum Srinivas (dims)'s message of 2016-04-18 14:27:48
-0400:
Josh,
So Andreas and i talked a bit, it seems like NONE of the oslo.* libs
except oslo.i18n needs a direct dependency on Babel. So we should yank
them all out and bump major versions
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/latest.log.html#t2016-04-18T11:58:10
I don't think we need to raise major versions to drop a dependency. We
only need to do that for backwards-incompatible changes, and this
doesn't seem to be one.
Doug
Thanks,
Dims
On Mon, Apr 18, 2016 at 1:42 PM, Joshua Harlow<harlo...@fastmail.com>
wrote:
Andreas Jaeger wrote:
On 04/17/2016 09:15 PM, Davanum Srinivas wrote:
Hi Oslo folks, Andreas and others,
Over the weekend oslo.log 3.4.0 was released. This broke keystone CI
jobs [2], even though the 3.4.0 was not specified in upper-constraints
as keystone jobs were not honoring the upper-constraints.txt, so we
fixed it in [3].
So the first big problem after [3] was that several tox targets do not
inject u-c and hence fail, so in [3] we also added install_commands
for testenv:releasenotes and testenv:cover, based on the pattern set
in Nova's tox.ini [4]. That was still not enough and we had to add an
entry in keystone's requirements.txt for Babel even though it was not
there before (and hence pulling in latest Babel from somewhere).
So Here are the questions:
1) Is there anyone working to fix all tox CI jobs to honor upper
constraints?
2) Why do we need Babel in oslo.log's requirements.txt?
3) Can we remove Babel from all requirements.txt and
test-requirements.txt and leave them in just tox.ini when needed?
Note that there was nothing wrong either in oslo.log itself it
published a release with what was in global-requirements.txt, nor in
keystone, which has traditionally not run with constraints on. Just
the combination of situations with Babel going bad broke at least
keystone.
Did anyone else see other jobs break? Please respond!
Thanks,
Dims
[1] http://markmail.org/message/ygyxpjpbhlbz3q5d
[2]
http://logs.openstack.org/86/249486/32/check/gate-keystone-python34-db/29ace4f/console.html#_2016-04-17_04_31_51_138
[3] https://review.openstack.org/#/c/306846/
[4] http://git.openstack.org/cgit/openstack/nova/tree/tox.ini
I think what happened is:
1) oslo.log indirectly requires Babel
2) requirements blacklists Babel 2.3.x
3) keystone has new requirements included and thus fails
The problem here is that oslo.log requires olso.i18n which requires
Babel. And if oslo.i18n would have had a release with the blacklisting
of Babel 2.3.x, this wouldn't have happened. So, I propose to release
oslo.i18n.
Babel 2.3.4 which fixes the known problems might be out soon as well -
and if that does not introduce regressions, this will self-heal,
Ok, so which option should we go with here?
I'm ok with releasing olso.i18n or Babel 2.3.4 (when is this release
happening, soon? like soon soon?)
Andreas
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
