Open Stack

On 01/13/2015 02:10 PM, Jay Pipes wrote:
> 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

I think as we grow global-requirements probably needs to be broken up
into functional lists. What's allowed in base-iass, what's allowed in
application services, what's allowed in docs, etc, etc.

The complexity of keeping the g-r list actually working goes up sort of
n^2 as the size of it, because pip doesn't have a real solver. This is a
barely functional set of plate spinning so "just add everything" misses
the point that the breaks get more and more difficult to unwind.

If someone is up for stepping up and contributing to breaking up into
"domains", please do. But I think while this remains a global list we
really do need to be a bit careful here.

>> 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
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-- 
Sean Dague
http://dague.net