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 wrote:
> We are working towards uncapping all the clients, with the ex
We are working towards uncapping all the clients, with the exception of
neutron client, because they need to make some incompatible changes on
their next major release.
On 07/12/2013 12:12 AM, Gareth wrote:
so, what's the final conclusion about this issue?
On Fri, Jul 12, 2013 at 12:11 PM, G
so, what's the final conclusion about this issue?
On Fri, Jul 12, 2013 at 12:11 PM, Gareth 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 https://review.openstack.org/#
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 (
https://jen
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 curr
On 07/11/2013 10:28 AM, Sean Dague wrote:
> 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
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 wrote:
> >> See for e
>> See for example https://bugs.launchpad.net/horizon/+bug/1196823
> This is arguably a deficiency of mox, which (apparently?) doesn't let us mock
> properties automatically.
I agree, but it is just one example. other test-only issues can happen as well.
Similar problem: the *client packages are
Hi Dirk,
"Dirk Müller" wrote:
> > 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 t
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:
https://review
On 07/11/2013 09:36 AM, Dolph Mathews wrote:
On Thu, Jul 11, 2013 at 6:12 AM, Mark McLoughlin mailto:mar...@redhat.com>> wrote:
On Wed, 2013-07-10 at 17:07 -0500, Dolph Mathews wrote:
> On Wednesday, July 10, 2013, Sean Dague wrote:
>
> > Yesterday in the very exciting run ar
On Thu, Jul 11, 2013 at 6:12 AM, Mark McLoughlin wrote:
> On Wed, 2013-07-10 at 17:07 -0500, Dolph Mathews wrote:
> > 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
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 rec
> 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
OpenStack-dev@lists.ope
good idea for global requirements
Let's submit a multi-project bug on launchpad, and be serious for changing
these global requirements in following days
On Thu, Jul 11, 2013 at 7:12 PM, Mark McLoughlin wrote:
> On Wed, 2013-07-10 at 17:07 -0500, Dolph Mathews wrote:
> > On Wednesday, July 10,
On Wed, 2013-07-10 at 17:07 -0500, Dolph Mathews wrote:
> 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 proje
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. T
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. The whole idea behind a single release chan
On 07/10/2013 06:07 PM, Dolph Mathews wrote:
>
> 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 proje
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 u
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 uni
21 matches
Mail list logo