Open Stack

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?

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