Open Stack

On Wed, Feb 3, 2016 at 3:49 AM, Sean Dague <sean at dague.net> wrote:

> I've been looking through the reviews on and where it's gotten to -
>
> https://review.openstack.org/#/c/243429/4/guidelines/microversion_specification.rst
>
>
> A couple of questions / concerns.
>
> There was major push back from API-WG on 'API' itself being in the
> headers. What is the data on what services are already doing? My
> understanding is this is convention for all every service so far, mostly
> because that's how we did it in Nova. Forcing a header change for that
> seems massively bike shed. There is zero value gained in such a change
> by anyone, and just confusion.
>
> On moving from code names to service types, I'm completely onboard with
> that providing value. However there is a bigger issue about the fact
> that service types don't really have a central registry. That's why Nova
> didn't do this up front because that's a whole other thing to figure out
> which has some really big implications on our community.
>
> Code names are self namespaced because they are based on git repo -
> openstack/nova, openstack/ironic. We get a registry for free that won't
> have conflicts.
>
> I actually agree these should be service types, however, that requires
> understanding how service types are going to be handed out. Having a
> project just start using 'monitoring' or 'policy' as a service type is
> going to go poorly in the long term when they get told they have to
> change that, and now all their clients are broken.
>
>
As part of the new catalog (x-project) spec we will also need the central
registry for deconflicting. If you're talking to "compute" via the catalog,
it needs to always be nova. I would like to see this be the service types.
For the projects that have used the code-names for now they can support
either/or favouring the new service type one in the long term.

Since we already need to solve this one way, we should use the same data
that is going to be in the catalog for this header.

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