[openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

Doug Hellmann doug at doughellmann.com
Thu May 12 20:33:02 UTC 2016

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-request at 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

More information about the OpenStack-dev mailing list