Open Stack

On 18:46 May 12, Nikhil Komawar wrote:
> I realized that I missed one of your questions earlier. Response for
> that inline.
> 
> 
> On 5/12/16 4:58 PM, Nikhil Komawar wrote:
> >
> >
> > On 5/12/16 4:33 PM, Doug Hellmann wrote:
> >> 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?
> 
> Currently, I do not have facts but only hints (anticipations, expected
> hick-ups). If you think that's not the case, do you think we can be done
> with all the processes, governance, etc. and yet be able to come up with
> a POC release (dunno something like 0.0.3) within next 5 weeks that can
> be experimented upon in one/two of the projects POC patches? We are
> looking at that timeline and not sure how long the governance and specs
> will take (do we need oslo spec?, how big is the process to setup
> sub-cores? , how do we involve more folks without them thinking of oslo
> standards?, etc.).
> 
> My biggest concern is that this will be seen as something that is an
> attempt to standardize things where we do not even have a standard but
> want to create one. We wish to be agile in our workflow and do not care
> where that exists.

Reading this thread, Nikhil who is speaking for the quota team is worried about
the amount of overhead caused by governance, instead of first focusing on
making something actually exist. I see quite a few people in this thread
speaking up that it should be part of the big tent either standalone or oslo
lib.

I can't speak for the Oslo folks, but as a member of the TC here are the
requirements for the standalone route [1]. You would propose an agenda item to
the TC, and we would review that the project meets those requirements.
Considering the project does Open Design and has an Open Community - my guesses
on "probably would be followed" is Open Development and Open Source since we
don't have anything but a specification that exists to go off of.

It sounds like the biggest hang up in going the oslo route is the oslo spec. So
question to the oslo folks, would you be interested in reviewing the
cross-project specification and allowing to be an oslo lib? That way the team
can focus on working on the library, and the community is happy it's part of
OpenStack already.

-- 
Mike Perez