Open Stack

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?
>
>>> 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