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

Nikhil Komawar nik.komawar at gmail.com
Thu May 12 19:40:05 UTC 2016

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




More information about the OpenStack-dev mailing list