On 01/14/2015 03:55 AM, Flavio Percoco wrote: > 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
We have the base infrastructure of that in devstack today with a SOFT requirements update - https://github.com/openstack-dev/devstack/blob/master/functions-common#L1696-L1704 If you are not in projects.txt, and you set your REQUIREMENTS_MODE=soft in your devstack run, we will leave extra dependencies untouched. Probably a few more bits required to make it really easy to expose, but that direction is also feasable. The reason I brought up domains though is that some groups really want the facility to have common requirements lists across a domain. Like the OpenStack Docs team. They've currently inserted a ton of stuff in g-r that really shouldn't be there because they have a lot of git trees, and the synchronization is a nice feature. However, if there were domain specific lists, that would be fine. A collection of projects that want to coordinate could all agree on a domain specific set of lists, and off we go. Maybe that list wouldn't even need to be contained in the main repo, it could be in a sub repo so have different approvers. -Sean -- Sean Dague http://dague.net
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
