[openstack-dev] [all] the trouble with names

Sean Dague sean at dague.net
Thu Feb 4 11:38:26 UTC 2016

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 -

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.

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 Dague

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160204/3fe59032/attachment.pgp>

More information about the OpenStack-dev mailing list