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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
@flaper87
Flavio Percoco

Attachment: pgpSTIBS8VTg9.pgp
Description: PGP signature

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to