Flavio, fyi, nova-docker is aspiring to be part of nova tree itself, but we had a couple of python libraries we needed for docker that are not in global, so we used the "soft" requirements to do that.
https://github.com/stackforge/nova-docker/blob/master/contrib/devstack/gate_hook.sh#L16 thanks, dims On Wed, Jan 14, 2015 at 7:50 AM, Sean Dague <s...@dague.net> wrote: > 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 > > > __________________________________________________________________________ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __________________________________________________________________________ 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