<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 3, 2016 at 3:49 AM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've been looking through the reviews on and where it's gotten to -<br>
<a href="https://review.openstack.org/#/c/243429/4/guidelines/microversion_specification.rst" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/243429/4/guidelines/microversion_specification.rst</a><br>
<br>
<br>
A couple of questions / concerns.<br>
<br>
There was major push back from API-WG on 'API' itself being in the<br>
headers. What is the data on what services are already doing? My<br>
understanding is this is convention for all every service so far, mostly<br>
because that's how we did it in Nova. Forcing a header change for that<br>
seems massively bike shed. There is zero value gained in such a change<br>
by anyone, and just confusion.<br>
<br>
On moving from code names to service types, I'm completely onboard with<br>
that providing value. However there is a bigger issue about the fact<br>
that service types don't really have a central registry. That's why Nova<br>
didn't do this up front because that's a whole other thing to figure out<br>
which has some really big implications on our community.<br>
<br>
Code names are self namespaced because they are based on git repo -<br>
openstack/nova, openstack/ironic. We get a registry for free that won't<br>
have conflicts.<br>
<br>
I actually agree these should be service types, however, that requires<br>
understanding how service types are going to be handed out. Having a<br>
project just start using 'monitoring' or 'policy' as a service type is<br>
going to go poorly in the long term when they get told they have to<br>
change that, and now all their clients are broken.<br>
<span><font color="#888888"><br></font></span></blockquote><div><br></div><div>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. <br><br></div><div>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.<br></div><div><br></div><div>--Morgan <br></div></div><br></div></div>