There're still keystone client conflict issues:
https://review.openstack.org/#/c/36684/
It seems uncapping keystone client(remove upper bound) in some else project
first is needed?
On Fri, Jul 12, 2013 at 7:25 PM, Sean Dague s...@dague.net wrote:
We are working towards uncapping all the
On 07/11/2013 05:06 AM, Thierry Carrez wrote:
Sean Dague wrote:
I think we need to get strict on projects and prevent them from capping
their client requirements. That will also put burden on clients that
they don't break backwards compatibility (which I think was a goal
regardless).
Indeed.
Let's submit a multi-project bug on launchpad, and be serious for changing
these global requirements in following days
https://bugs.launchpad.net/keystone/+bug/1200214
created.
Greetings,
Dirk
___
OpenStack-dev mailing list
Hi Thierry,
Indeed. The whole idea behind a single release channel for python client
libraries was that you should always be running the latest, as they
should drastically enforce backward compatibility.
Well, backward compatibility can be tricky when it comes to test.
We've for example
On 07/11/2013 09:12 AM, Dirk Müller wrote:
Let's submit a multi-project bug on launchpad, and be serious for changing
these global requirements in following days
https://bugs.launchpad.net/keystone/+bug/1200214
Great!
This is the first review we need to land to make progress:
I heard there's a talk about this issue in #openstack-infra last night
(china standard time), what's the conclusion of that?
BTW, how to find meeting log of #openstack-infra? I didn't find it in
http://eavesdrop.openstack.org/
On Thu, Jul 11, 2013 at 11:35 PM, Dirk Müller d...@dmllr.de wrote:
On 07/11/2013 11:38 PM, Gareth wrote:
I heard there's a talk about this issue in #openstack-infra last night
(china standard time), what's the conclusion of that?
BTW, how to find meeting log of #openstack-infra? I didn't find it
in http://eavesdrop.openstack.org/
We don't log it
Thanks, Monty
but in my review https://review.openstack.org/#/c/36684/ , Doug said we
will go without upper bound with those python-*clients
and in this one https://review.openstack.org/#/c/36753/ , keystoneclient
still keep '0.4' and requirements test doesn't fail in keystoneclient (
so, what's the final conclusion about this issue?
On Fri, Jul 12, 2013 at 12:11 PM, Gareth academicgar...@gmail.com wrote:
Thanks, Monty
but in my review https://review.openstack.org/#/c/36684/ , Doug said we
will go without upper bound with those python-*clients
and in this one
Yesterday in the very exciting run around to figure out why the gate was
broken, we realized something interesting. Because of the way the gate
process pip requirements (one project at a time), on a current gate run
we actually install and uninstall python-keystoneclient 4 times in a
normal
On Wednesday, July 10, 2013, Sean Dague wrote:
Yesterday in the very exciting run around to figure out why the gate was
broken, we realized something interesting. Because of the way the gate
process pip requirements (one project at a time), on a current gate run we
actually install and
A useful tool that anvil has built into it (thanks to aababilov). It might
be useful in this situation.
https://github.com/stackforge/anvil/tree/master/tools#multipip
It might be useful to use said tool (or a derivative) to detect this kind
of version conflict earlier rather than later??
It is
12 matches
Mail list logo
