Open Stack

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 -
>     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.
>

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[1], 
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.

regards,
mike

[1]: 
http://lists.openstack.org/pipermail/openstack-dev/2016-February/085748.html