Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future

2013-07-12 Thread Gareth
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

Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future

2013-07-11 Thread Sean Dague
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.

Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future

2013-07-11 Thread Mark McLoughlin
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 project at a

Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future

2013-07-11 Thread Gareth
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 mar...@redhat.com wrote: On Wed, 2013-07-10 at 17:07 -0500, Dolph Mathews wrote: On

Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future

2013-07-11 Thread Dirk Müller
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

Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future

2013-07-11 Thread Dirk Müller
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

Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future

2013-07-11 Thread Dolph Mathews
On Thu, Jul 11, 2013 at 6:12 AM, Mark McLoughlin 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 around to figure out why the gate was broken, we realized something

Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future

2013-07-11 Thread Sean Dague
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:

Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future

2013-07-11 Thread Dirk Müller
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

Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future

2013-07-11 Thread Gareth
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:

Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future

2013-07-11 Thread Monty Taylor
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 the first review

Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future

2013-07-11 Thread Monty Taylor
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

Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future

2013-07-11 Thread Gareth
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 (

Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future

2013-07-11 Thread Gareth
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

Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future

2013-07-10 Thread Dolph Mathews
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

Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future

2013-07-10 Thread Joshua Harlow
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