Open Stack

Excerpts from Sean Dague's message of 2016-02-04 08:33:59 -0500:
> On 02/04/2016 08:18 AM, Doug Hellmann wrote:
> > Excerpts from Hayes, Graham's message of 2016-02-04 12:54:56 +0000:
> >> On 04/02/2016 11:40, Sean Dague wrote:
> >>> 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.
> >>
> >> ++ to a central registry. It could easily be added to the projects.yaml
> >> file, and is a single source of truth.
> > 
> > Although I realized that the projects.yaml file only includes official
> > projects right now, which would mean new projects wouldn't have a place
> > to register terms. Maybe that's a feature?
> 
> It seems like it's a feature.
> 
> That being said, projects.yaml is pretty full right now. And, it's not
> clear that common name <-> project name is a 1 to 1 mapping.
> 
> For instance, Nova is getting very close to exposing a set of scheduler
> resources. For future proofing we would like to do that on a dedicated
> new endpoint from day one so that potential future split out of the code
> would not impact how APIs look in the service catalog or to consumers.
> There would be no need to have proxy apis in Nova for compatibility in
> the future.
> 
> So this feels like a separate registry for service common name, which
> maps N -> 1 to a project.

We already map multiple repos to multiple deliverables to multiple
projects. So I don't think the schema concerns are a reason not to have
it in projects.yaml. That said, it doesn't *have* to be there, it would
just make it convenient to manage publication.

Doug

> 
>     -Sean
>