Open Stack

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.

>>
>>>> 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?
>>
> But we are not working in a corner, we've a representative from cinder,
> someone from trove who is interested in long term quota goals, someone
> who has worked on nova (and then we are borrowing the gen_id concept of
> Jay from Nova), someone from Zaqar, a PWG representative who is also
> collaborating on UX study, someone who is interested from vmware's
> perspective. And then we are developing this on the #openstack-irc
> channel, ML, weekly meetings etc.
>
> Once some code is published, we will reflect back on the cross project
> meetings to where things are heading.
>
>>> 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
>>>
>> __________________________________________________________________________
>> 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
>>
>>
>

-- 

Thanks,
Nikhil