Open Stack

I can't make the meeting today but I would have wanted to discuss

Step four make sure tempest has adequate tests to detect incompatible 
changes in client python apis. I think this would require two steps:

1. Make sure we have good coverage of the client apis, perhaps by making 
sure the scenario tests cover widely
2. Run the scenario tests of previous api versions using clients from master

This is kind of tricky.

  -David


-------- Original Message --------
Subject: 	Re: [openstack-dev] The danger of capping python-*clients in 
core projects, and forbidding it in the future
Date: 	Thu, 11 Jul 2013 06:38:26 -0400
From: 	Sean Dague <sean at dague.net>
Reply-To: 	OpenStack Development Mailing List 
<openstack-dev at lists.openstack.org>
To: 	openstack-dev at lists.openstack.org



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. 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.
>
> Any reason why those caps were introduced in the first place ?

Well global requirements specifies caps for most clients:

python-cinderclient>=1.0.4,<2
python-ceilometerclient>=1.0.1
python-heatclient>=0.2.2
python-glanceclient>=0.9.0,<2
python-keystoneclient>=0.2.1,<0.4
python-memcached
python-neutronclient>=2.2.3,<3.0.0
python-novaclient>=2.12.0,<3
python-quantumclient>=2.2.0,<3.0.0
python-swiftclient>=1.2,<2

I assume projects just copied those lines into their requirements. Then
keystoneclient bumped release number, and got outside the boundary that
was allowed by some project.

I know a flury of python-keystoneclient patches went in after
python-keystoneclient 0.3.0 released, but has a broken compatibility issue.

So step one is purge from global requirements.

Step two purge from projects.

Step three enforce they don't come back.

	-Sean

-- 
Sean Dague
http://dague.net

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-qa/attachments/20130711/ae3e3836/attachment.html>