Excerpts from Nikhil Komawar's message of 2016-05-12 15:40:05 -0400: > 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.
I'm not sure what processes you're talking about that might be a burden. Can you elaborate? > > > 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. If you go off in a corner and build something that doesn't fit any of our community standards for code or API, how do you expect the adoption process to work out? > > 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 > __________________________________________________________________________ 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
