Open Stack

On 5/14/16 2:35 PM, Mike Perez wrote:
> 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.
>
>
>

Thanks Mike for helping us move forward.

After having been suggested yesterday, I have added this agenda item for
the Oslo team meeting to get the answers
https://wiki.openstack.org/wiki/Meetings/Oslo#Agenda_for_Next_Meeting .

Also, can you please re-reference as the link did not come through?

-- 

Thanks,
Nikhil