Open Stack

On Thu, Feb 4, 2016 at 4:51 AM, Doug Hellmann <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".

[1]
https://github.com/openstack/os-client-config/blob/master/os_client_config/constructors.json

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