<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 4, 2016 at 4:51 AM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Excerpts from Sean Dague's message of 2016-02-04 06:38:26 -0500:<br>
<div><div class="h5">> A few issues have crept up recently with the service catalog, API<br>
> headers, API end points, and even similarly named resources in different<br>
> resources (e.g. backup), that are all circling around a key problem.<br>
> Distributed teams and naming collision.<br>
><br>
> Every OpenStack project has a unique name by virtue of having a git<br>
> tree. Once they claim 'openstack/foo', foo is theirs in the OpenStack<br>
> universe for all time (or until trademarks say otherwise). Nova in<br>
> OpenStack will always mean one project.<br>
><br>
> There has also been a desire to replace project names with<br>
> common/generic names, in the service catalog, API headers, and a few<br>
> other places. Nova owns 'compute'. Except... that's only because we all<br>
> know that it does. We don't *actually* have a registry for those values.<br>
><br>
> So the code names are well regulated, the common names, that we<br>
> encourage use of, are not. Devstack in tree code defines some<br>
> conventions. However with the big tent, things get kind of squirely<br>
> pretty quickly. Congress registering 'policy' as their endpoint type is<br>
> a good example of that -<br>
> <a href="https://github.com/openstack/congress/blob/master/devstack/plugin.sh#L147" rel="noreferrer" target="_blank">https://github.com/openstack/congress/blob/master/devstack/plugin.sh#L147</a><br>
><br>
> Naming is hard. And trying to boil down complicated state machines to<br>
> one or two word shiboliths means that inevitably we're going to find<br>
> some words just keep cropping up: policy, flavor, backup, meter. We do<br>
> however need to figure out a way forward.<br>
><br>
> Lets start with the top level names (resource overlap cascades from there).<br>
><br>
> What options do we have?<br>
><br>
> 1) Use the names we already have: nova, glance, swift, etc.<br>
><br>
> Upside, collision problem is solved. Downside, you need a secret decoder<br>
> ring to figure out what project does what.<br>
><br>
> 2) Have a registry of "common" names.<br>
><br>
> Upside, we can safely use common names everywhere and not fear collision<br>
> down the road.<br>
><br>
> Downside, yet another contention point.<br>
><br>
> A registry would clearly be under TC administration, though all the<br>
> heavy lifting might be handed over to the API working group. I still<br>
> imagine collision around some areas might be contentious.<br>
><br>
> 3) Use either, inconsistently, hope for the best. (aka - status quo)<br>
><br>
> Upside, no long mailing list thread to figure out the answer. Downside,<br>
> it sucks.<br>
><br>
><br>
> Are there other options missing? Where are people leaning at this point?<br>
><br>
> Personally I'm way less partial to any particular answer as long as it's<br>
> not #3.<br>
><br>
><br>
>     -Sean<br>
><br>
<br>
</div></div>This feels like something that should be designed with end-users<br>
in mind, and that means making choices about descriptive words<br>
rather than quirky in-jokes.  As much as I hate to think about the<br>
long threads some of the contention is likely to introduce, not to<br>
mention the bikeshedding over the terms themselves, I have become<br>
convinced that our best long-term solution is a term/name registry<br>
(option 2). We already have that pattern in the governance repository<br>
where official projects describe their service type.<br>
<br>
To reduce contention, we could agree in advance to support multi-word<br>
names ("block storage" and "object storage", "block backup" and<br>
"file backup", etc.). Decisions about noun-verb vs. verb-noun,<br>
punctuation, etc. can be dealt with by the group that takes on the<br>
task of setting standards.<br>
<br>
As I said in the TC meeting, this seems like something the API working<br>
group could do, if they wanted to take on the responsibility. If not,<br>
then we should establish a new group with a mandate from the TC. Since<br>
we have something like a product catalog already in the governance repo,<br>
we can keep the new data there.<br>
<br>
Doug<br></blockquote><div><br></div><div>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.<br><br></div><div>I am very against "hope for the best options".<br><br>[1] <a href="https://github.com/openstack/os-client-config/blob/master/os_client_config/constructors.json">https://github.com/openstack/os-client-config/blob/master/os_client_config/constructors.json</a><br><br></div><div>--Morgan<br></div></div></div></div>