Open Stack

On 04/02/2016 13:24, Doug Hellmann wrote:
> Excerpts from Hayes, Graham's message of 2016-02-04 12:54:56 +0000:
>> On 04/02/2016 11:40, Sean Dague wrote:
>>> A few issues have crept up recently with the service catalog, API
>>> headers, API end points, and even similarly named resources in
>>> different resources (e.g. backup), that are all circling around a key
>>> problem. Distributed teams and naming collision.
>>>
>>> Every OpenStack project has a unique name by virtue of having a git
>>> tree. Once they claim 'openstack/foo', foo is theirs in the
>>> OpenStack universe for all time (or until trademarks say otherwise).
>>> Nova in OpenStack will always mean one project.
>>>
>>> There has also been a desire to replace project names with
>>> common/generic names, in the service catalog, API headers, and a few
>>> other places. Nova owns 'compute'. Except... that's only because we
>>> all know that it does. We don't *actually* have a registry for those
>>> values.
>>>
>>> So the code names are well regulated, the common names, that we
>>> encourage use of, are not. Devstack in tree code defines some
>>> conventions. However with the big tent, things get kind of squirely
>>> pretty quickly. Congress registering 'policy' as their endpoint type
>>> is a good example of that -
>>> https://github.com/openstack/congress/blob/master/devstack/plugin.sh#L147
>>>
>>>   Naming is hard. And trying to boil down complicated state machines
>>> to one or two word shiboliths means that inevitably we're going to
>>> find some words just keep cropping up: policy, flavor, backup, meter.
>>> We do however need to figure out a way forward.
>>>
>>> Lets start with the top level names (resource overlap cascades from
>>> there).
>>>
>>> What options do we have?
>>>
>>> 1) Use the names we already have: nova, glance, swift, etc.
>>>
>>> Upside, collision problem is solved. Downside, you need a secret
>>> decoder ring to figure out what project does what.
>>>
>>> 2) Have a registry of "common" names.
>>>
>>> Upside, we can safely use common names everywhere and not fear
>>> collision down the road.
>>>
>>> Downside, yet another contention point.
>>>
>>> A registry would clearly be under TC administration, though all the
>>> heavy lifting might be handed over to the API working group. I still
>>> imagine collision around some areas might be contentious.
>>
>> ++ to a central registry. It could easily be added to the projects.yaml
>> file, and is a single source of truth.
>
> Although I realized that the projects.yaml file only includes official
> projects right now, which would mean new projects wouldn't have a place
> to register terms. Maybe that's a feature?

That is a good point - should we be registering terms for non tent
projects? Or do projects get terms when they get accepted into the tent?

>
>>
>> I imagine collisions are going to be contentious - but having a central
>> source makes finding potential collisions much easier.
>>
>>>
>>> 3) Use either, inconsistently, hope for the best. (aka - status quo)
>>>
>>> Upside, no long mailing list thread to figure out the answer.
>>> Downside, it sucks.
>>>
>>>
>>> Are there other options missing? Where are people leaning at this
>>> point?
>>>
>>> Personally I'm way less partial to any particular answer as long as
>>> it's not #3.
>>>
>>>
>>> -Sean
>>>
>>
>
> __________________________________________________________________________
> 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
>