Open Stack

On Thu, Feb 4, 2016 at 7:33 AM, Sean Dague <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?

API design and developer experience must become our first thought.

Anne


>
>         -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Anne Gentle
Rackspace
Principal Engineer
www.justwriteclick.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160204/f44ddace/attachment.html>