Open Stack

On 13/01/15 14:31 -0500, Sean Dague wrote:
>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.

Do we really need a per-domain g-r?

With the upcoming changes in the openstack governance model, I believe
this won't scale even if we break it into per-domain basis. Some
questions that need answeres are:

- Who's going to review the per domain g-r ?

If it's a centralized team, then it won't definitely scale. If it's
the domain team then, what's the real point of having these
requirements?

- How are we going to support the creation and maintnance of these g-r
  in the gate? Are they actually worth it?


While I understand why we have g-r, I really don't think it'll scale
for a broader community as we're envisioning it. With that in mind,
I'd probably recommend to have 1 requirements group for the base-caas
integrated gate and let other projects and groups have their own
requirements. That is, non base-caas projects should get the versions
of their common requirements from g-r so that they won't conflict if
they're installed alongside with any of the base-caas projects. But
other than those base requirements, I'd let non base-caas projects
have what they need (which is pretty much what heat's team has done
with the contrib packages, AFAICT).

I know this opens the doors for version conflicts between the
requirements of non base-caas projects but I think this is a more
welcoming (and non-blocking) way to do things until we've a better
one.

Hope the above makes some sense.... I blame the lack of coffee if it
doesn't,
Flavio
>>> 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
>
>__________________________________________________________________________
>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

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150114/bb4a2084/attachment.pgp>