On Thu, Feb 4, 2016 at 4:51 AM, Doug Hellmann <d...@doughellmann.com> wrote:
> Excerpts from Sean Dague's message of 2016-02-04 06:38:26 -0500: > > 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 > > > > This feels like something that should be designed with end-users > in mind, and that means making choices about descriptive words > rather than quirky in-jokes. As much as I hate to think about the > long threads some of the contention is likely to introduce, not to > mention the bikeshedding over the terms themselves, I have become > convinced that our best long-term solution is a term/name registry > (option 2). We already have that pattern in the governance repository > where official projects describe their service type. > > To reduce contention, we could agree in advance to support multi-word > names ("block storage" and "object storage", "block backup" and > "file backup", etc.). Decisions about noun-verb vs. verb-noun, > punctuation, etc. can be dealt with by the group that takes on the > task of setting standards. > > As I said in the TC meeting, this seems like something the API working > group could do, if they wanted to take on the responsibility. If not, > then we should establish a new group with a mandate from the TC. Since > we have something like a product catalog already in the governance repo, > we can keep the new data there. > > Doug > I am a fan of option #2. I also want to point out that os-client-config has encoded some of these names as well[1], which is pushing us in the direction of #2. I 100% agree that the end user perspective also leans us towards option #2. I am very against "hope for the best options". [1] https://github.com/openstack/os-client-config/blob/master/os_client_config/constructors.json --Morgan
__________________________________________________________________________ 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
