Open Stack

On 01/13/2015 12:39 PM, Zane Bitter wrote:
> 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.

+1

> 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.

Seems like a very reasonable solution to me.

Thanks for bringing it up,
-jay