On 02/04/2016 09:35 AM, Anne Gentle wrote:
>
>
> On Thu, Feb 4, 2016 at 7:33 AM, Sean Dague <s...@dague.net
> <mailto:s...@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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
