Open Stack

On 13/01/15 10:01, Jeremy Stanley wrote:
> On 2015-01-13 07:46:38 -0500 (-0500), Sean Dague wrote:
>> Why doesn't rally just remove itself from projects.txt, then there
>> would be no restrictions on what it adds.
>
> I second this recommendation. If Rally wants to depend on things
> which are not part of OpenStack and not required to run or test
> OpenStack in an official capacity (and since it's not an official
> OpenStack project it's entirely within its rights to want to do
> that), then forcing it to comply with the list of requirements for
> official OpenStack projects is an unnecessarily restrictive choice.

FWIW I don't really agree with this advice. The purpose of 
openstack/requirements is to ensure that it's possible to create a 
distribution of OpenStack without conflicting version requirements, not 
to force every project to use every dependency listed. As such, some 
co-ordination around client libraries for related projects seems like it 
ought to be an uncontroversial addition. (Obviously it's easy to imagine 
potential additions that would legitimately be highly controversial, but 
IMHO this isn't one of them.) Saying that we require people to use our 
tools to get into the club but that our tools are not going to 
accommodate them in any way until they are in sounds a bit too close to 
"Go away" to my ears.


That said, I'd like to suggest another possible workaround: in Heat we 
keep resource plugins for non-official projects in the /contrib tree, 
and each plugin has it's own setup.cfg and requirements.txt. For example:

http://git.openstack.org/cgit/openstack/heat/tree/contrib/heat_barbican

So the user has the option to install each plugin, and it comes with its 
own requirements, independent of the main Heat installation. Perhaps 
Rally could consider something similar.

cheers,
Zane.