Open Stack

On 02/04/2016 08:18 AM, 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?

It seems like it's a feature.

That being said, projects.yaml is pretty full right now. And, it's not
clear that common name <-> project name is a 1 to 1 mapping.

For instance, Nova is getting very close to exposing a set of scheduler
resources. For future proofing we would like to do that on a dedicated
new endpoint from day one so that potential future split out of the code
would not impact how APIs look in the service catalog or to consumers.
There would be no need to have proxy apis in Nova for compatibility in
the future.

So this feels like a separate registry for service common name, which
maps N -> 1 to a project.

	-Sean

-- 
Sean Dague
http://dague.net