On 02/03/2016 10:23 AM, Morgan Fainberg wrote:
On Wed, Feb 3, 2016 at 3:49 AM, Sean Dague <s...@dague.net
<mailto:s...@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
__________________________________________________________________________
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
