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.+1I 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
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
