[openstack-dev] [api] microversion spec
msm at redhat.com
Fri Feb 5 20:00:18 UTC 2016
On 02/03/2016 10:23 AM, Morgan Fainberg wrote:
> On Wed, Feb 3, 2016 at 3:49 AM, Sean Dague <sean at dague.net
> <mailto:sean at dague.net>> wrote:
> I've been looking through the reviews on and where it's gotten to -
> 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.
i don't see a conflict with the guideline proposing removing API from
the header. if nova moves to support both headers in the future that
would be awesome, but not strictly necessary.
i think what we wanted was to make sure that new projects will be on the
same page about this. (although, i can understand that they will cry
"but nova doesn't do that")
> 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.
agreed about the need for a registry, or something, to help coordinate
the service type names. as stated in the other thread about naming,
i'm ok with starting to work on some sort of plan for the api-wg to
assist in the registration efforts, but that will take some time.
in the short term, i think we should forge ahead with standardizing on
service type, and when the registry, or w/e, exists we can start to
bring things into congruence with each other.
More information about the OpenStack-dev