Please find my response inline:
On 5/12/16 1:10 PM, Doug Hellmann wrote: > Excerpts from Thierry Carrez's message of 2016-05-12 13:37:32 +0200: >> Tim Bell wrote: >>> [...] >>> I think it will be really difficult to persuade the mainstream projects to >>> adopt >>> a library if it is not part of Oslo. Developing a common library for quota >>> management outside the scope of the common library framework for OpenStack >>> does not seem to be encouraging the widespread use of delimiter. >>> [...] >> I agree it's hard enough to get Oslo libraries used across the board, I >> don't think the task would be any easier with an external library. >> >> One case that would justify being external is if the library was >> generally useful rather than OpenStack-specific: then the Oslo branding >> might hinder its out-of-OpenStack adoption. But it doesn't feel like >> that is the case here ? >> > In the past we've tried to encourage folks creating very specially > focused libraries for which areas where the existing Oslo team has no > real experience, such as os-win, to set up their own team. The Oslo team > doesn't have to own all libraries. Thanks for that pointer! > On the other hand, in this case I think quota management fits in Oslo as > well as messaging or policy do. We have a mechanism in place for managing > sub-teams so signing up to work on quotas doesn't have to mean signing > up to be oslo-core. Yes, I agree that this fits well into the cross-project consistency domain. And yes, thanks for proposing the sub-team strategy to move forward. However, this library currently doesn't exist. We are still identifying what we want to achieve as a part of this scope, there's a ton of discussions in progress and we are on the advent of finding concrete tasks for people to pick up (so no second commit yet). Even after having done something we do not know if that's is something which will work for all the projects -- basically I am trying to say quotas is a big domain and now we are starting (very) small. We need a concrete implementation and it's adoption in a couple of projects to even say that it is a successful cross project implementation. The last thing we want to worry about is more process, governance and an approach to too-standardize things when we do not even have anything in tree. I think it makes sense as a part of somewhere _all_ projects can adopt but not until it's ready to be adopted. > The notion that we're going to try to have all projects depend on > something we create but that we *don't* create as part of an official > project is extremely confusing. Whether we make it part of Oslo or part > of its own thing, I think we want this to be official. Yes, that exists as a notion but it's agreed upon in the ML thread [1] that it's not practical yet. The hardest thing to achieve is to get the quotas code right and for now we would please like to focus on that. We do want to worry about governance and adoption across domain (standardization) once we do have a standard. With that mind, please suggest the path of least resistance for moving forward quickly on this. We have seen good interest in the library and we want people to start working on things without having to wait on decisions they are not interested in. We do, however, want to be compliant with the governance rules so that it does not diverge too far. Simply put, can we revisit the governance decision late in Newton? > Before pushing too hard to bring the new lib under the Oslo umbrella, > I'd like to understand why folks might not want to do that. What "costs" > are perceived? Much appreciated! > > Doug > > __________________________________________________________________________ > 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 [1] http://lists.openstack.org/pipermail/openstack-dev/2016-March/thread.html#89453 -- Thanks, Nikhil __________________________________________________________________________ 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
