Open Stack

On 02/04/2016 09:35 AM, Anne Gentle wrote:
> 
> 
> On Thu, Feb 4, 2016 at 7:33 AM, Sean Dague <sean at dague.net
> <mailto:sean at dague.net>> wrote:
> 
>     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.
> 
> 
> Project names should not be exposed to end users.
> 
> Maybe the service names belong in an example, vetted service catalog as
> a place to look to see if your name is already taken. I sense we have to
> first start with endpoints, then move to the resources, and honestly I
> feel lately "let the best API design win." For example, with PayPal and
> Stripe, there are differentiators that would cause a dev to choose one
> over another. PayPal has a /payments resource and Stripe has a /charges
> resource. Those resources are where some of the conflict is starting to
> be seen for us in OpenStack with backups. If we expect end users to use
> the whole cloud then we need to outline the resources that are reserved
> already to avoid end-user confusion. Believe me, I document this stuff,
> and I know it's difficult to understand. We have to advocate for our end
> users now, today, here.
> 
> For the schedule example, is it the Compute endpoint that intakes the
> scheduling operations? Or is there a new endpoint?

The intent is a new dedicated endpoint, to ensure an easy migration to
any future dedicated code base.

	-Sean

-- 
Sean Dague
http://dague.net