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. 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 -- Sean Dague http://dague.net
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ 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