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. 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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev