Open Stack

On 04/02/2016 9:04 AM, Morgan Fainberg wrote:


On Thu, Feb 4, 2016 at 4:51 AM, Doug Hellmann <doug at doughellmann.com<mailto:doug at 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".
i'm inclined to say #2 as well since the code names, based on my experience, lead to assumptions of what the project covers/does based on an elevator pitch description someone heard one time.

i definitely agree that we shouldn't concern ourselves with non big tent projects.

my concern with #2 is, we will just end up going to thesaurus.com and searching for alternate words that mean the same general thing and this will be equally confusing. with the big tent, we essentially agreed that duplication is possible, so no matter how granular we make the scope, i'm not sure there's a way for any project to own a domain anymore. it seems this question is better addressed by addressing how the TC should handle big tent first?

cheers,

--
gord
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160204/8e6ca4d1/attachment.html>