Re: [openstack-dev] Version header for OpenStack microversion support

2016-06-21 Thread Monty Taylor 
On 06/21/2016 10:27 AM, Sean Dague wrote:
> On 06/21/2016 10:47 AM, Monty Taylor wrote:
> 
>>
>> I'll agree with Clint here, and give an example.
>>
>> When I talk to Nova and get a detail record for a server, Nova talks to
>> Neutron and puts data that it receives into the addresses dict on the
>> server record. This is not the neutron data structure. In fact, it has
>> some information from the Network and some from the Port (it would be
>> helpful if it had _more_ info, but that's not the point here)
>>
>> In any case, the data structure returned by Nova is not related in any
>> way to the version of Neutron that nova is talking to - nor should it be.
>>
>> Here's an example (in yaml not json)
>>
>>   addresses:
>> GATEWAY_NET:
>> - OS-EXT-IPS-MAC:mac_addr: fa:16:3e:ea:d8:0d
>>   OS-EXT-IPS:type: fixed
>>   addr: 172.99.106.178
>>   version: 4
>>
>> If you want a neutron record, you'll talk to neutron.
> 
> That's all well and good today, with all the things that we know about
> today. And says nothing about what the Neutron API looks like in 6 years
> time. Let's say that Neutron decides in 2020 that "fixed" is a non
> meaningful name, and stops using it.
> 
> We just did a transition in Nova interacting with Glance where we *could
> not* guarantee the semantics of the interaction from before. We decided
> to *shrug* and just break it, because the only other option was to pin
> to Glance v1 API for eternity.
> 
> So just because you can't imagine a situation right now where this isn't
> a problem, doesn't mean that it's not going to hit you. And the API is a
> place where we don't really get do overs without hurting users.
> 
> ...
> 
> And getting back to the point of the argument it's all about:
> 
> OpenStack-API-Version: compute 2.11
> 
> vs.
> 
> OpenStack-API-Version: 2.11
> 
> 8 bytes to be more explicit on our ACK, and to allow flexibility for
> composite actions in the future (which may never be used, so 8 bytes is
> our cost).

I think putting compute in the argument is a GREAT idea. Sorry, I should
have been much clearer on that.

I was mostly arguing that regardless of where Nova gets its data, if I'm
talking to Nova then it's Nova's api version I care about. I think
expecting me to need to also set a neutron microversion header when
talking to nova is a _terrible_ user experience, and if neutron were to
do something that would make it unpossible for nova to fulfill its API
contract, then we, as OpenStack, should say no.

Monty

__
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

Re: [openstack-dev] Version header for OpenStack microversion support

2016-06-21 Thread Sean Dague 
On 06/21/2016 10:47 AM, Monty Taylor wrote:

> 
> I'll agree with Clint here, and give an example.
> 
> When I talk to Nova and get a detail record for a server, Nova talks to
> Neutron and puts data that it receives into the addresses dict on the
> server record. This is not the neutron data structure. In fact, it has
> some information from the Network and some from the Port (it would be
> helpful if it had _more_ info, but that's not the point here)
> 
> In any case, the data structure returned by Nova is not related in any
> way to the version of Neutron that nova is talking to - nor should it be.
> 
> Here's an example (in yaml not json)
> 
>   addresses:
> GATEWAY_NET:
> - OS-EXT-IPS-MAC:mac_addr: fa:16:3e:ea:d8:0d
>   OS-EXT-IPS:type: fixed
>   addr: 172.99.106.178
>   version: 4
> 
> If you want a neutron record, you'll talk to neutron.

That's all well and good today, with all the things that we know about
today. And says nothing about what the Neutron API looks like in 6 years
time. Let's say that Neutron decides in 2020 that "fixed" is a non
meaningful name, and stops using it.

We just did a transition in Nova interacting with Glance where we *could
not* guarantee the semantics of the interaction from before. We decided
to *shrug* and just break it, because the only other option was to pin
to Glance v1 API for eternity.

So just because you can't imagine a situation right now where this isn't
a problem, doesn't mean that it's not going to hit you. And the API is a
place where we don't really get do overs without hurting users.

...

And getting back to the point of the argument it's all about:

OpenStack-API-Version: compute 2.11

vs.

OpenStack-API-Version: 2.11

8 bytes to be more explicit on our ACK, and to allow flexibility for
composite actions in the future (which may never be used, so 8 bytes is
our cost).

-Sean

-- 
Sean Dague
http://dague.net

__
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

Re: [openstack-dev] Version header for OpenStack microversion support

2016-06-21 Thread Monty Taylor 
On 06/21/2016 12:59 AM, Clint Byrum wrote:
> Excerpts from Edward Leafe's message of 2016-06-20 20:41:56 -0500:
>> On Jun 18, 2016, at 9:03 AM, Clint Byrum  wrote:
>>
>>> Whatever API version is used behind the compute API is none of the user's
>>> business.
>>
>> Actually, yeah, it is.
>>
>> If I write an app or a tool that expects to send information in a certain 
>> format, and receive responses in a certain format, I don't want that to 
>> change when the cloud operator upgrades their system. I only want things to 
>> change when I specifically request that they change by specifying a new 
>> microversion.
>>
> 
> The things I get back in the compute API are the purview of the compute
> API, and nothing else.
> 
> Before we go too far down this road, is there actually an example of
> one API providing a proxy to another directly? If so, is it something
> we think is actually a good idea?
> 
> Because otherwise, the API I'm talking to needs to be clear about what
> it does and does not emit and/or accept. That contract would just be
> the microversion of the API I'm talking to.

I'll agree with Clint here, and give an example.

When I talk to Nova and get a detail record for a server, Nova talks to
Neutron and puts data that it receives into the addresses dict on the
server record. This is not the neutron data structure. In fact, it has
some information from the Network and some from the Port (it would be
helpful if it had _more_ info, but that's not the point here)

In any case, the data structure returned by Nova is not related in any
way to the version of Neutron that nova is talking to - nor should it be.

Here's an example (in yaml not json)

  addresses:
GATEWAY_NET:
- OS-EXT-IPS-MAC:mac_addr: fa:16:3e:ea:d8:0d
  OS-EXT-IPS:type: fixed
  addr: 172.99.106.178
  version: 4

If you want a neutron record, you'll talk to neutron.

__
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

Re: [openstack-dev] Version header for OpenStack microversion support

2016-06-21 Thread Sean Dague 
On 06/21/2016 01:59 AM, Clint Byrum wrote:
> Excerpts from Edward Leafe's message of 2016-06-20 20:41:56 -0500:
>> On Jun 18, 2016, at 9:03 AM, Clint Byrum  wrote:
>>
>>> Whatever API version is used behind the compute API is none of the user's
>>> business.
>>
>> Actually, yeah, it is.
>>
>> If I write an app or a tool that expects to send information in a certain 
>> format, and receive responses in a certain format, I don't want that to 
>> change when the cloud operator upgrades their system. I only want things to 
>> change when I specifically request that they change by specifying a new 
>> microversion.
>>
> 
> The things I get back in the compute API are the purview of the compute
> API, and nothing else.
> 
> Before we go too far down this road, is there actually an example of
> one API providing a proxy to another directly? If so, is it something
> we think is actually a good idea?

There are a ton of pure proxies in Nova, which are now getting
deprecated. We do have semantic break on the images proxy in Newton
because Glance v2 has different data restrictions than Glance v1.
(metadata keys are now case sensitive, and certain properties are now
reserve words).

> Because otherwise, the API I'm talking to needs to be clear about what
> it does and does not emit and/or accept. That contract would just be
> the microversion of the API I'm talking to.

Which is fine and good in theory, and it's the theory that we're working
on. But some resources, like servers, are pretty useless without network
information, which isn't owned by Nova any more. While I don't currently
anticipate a way we couldn't mash whatever we get from Neutron into the
current format, I also have been surprised enough by future software
evolution to feel more comfortable that we have a backup plan that
includes a signaling mechanism should we need it.

-Sean

-- 
Sean Dague
http://dague.net

__
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

Re: [openstack-dev] Version header for OpenStack microversion support

2016-06-21 Thread Clint Byrum 
Excerpts from Edward Leafe's message of 2016-06-20 20:41:56 -0500:
> On Jun 18, 2016, at 9:03 AM, Clint Byrum  wrote:
> 
> > Whatever API version is used behind the compute API is none of the user's
> > business.
> 
> Actually, yeah, it is.
> 
> If I write an app or a tool that expects to send information in a certain 
> format, and receive responses in a certain format, I don't want that to 
> change when the cloud operator upgrades their system. I only want things to 
> change when I specifically request that they change by specifying a new 
> microversion.
> 

The things I get back in the compute API are the purview of the compute
API, and nothing else.

Before we go too far down this road, is there actually an example of
one API providing a proxy to another directly? If so, is it something
we think is actually a good idea?

Because otherwise, the API I'm talking to needs to be clear about what
it does and does not emit and/or accept. That contract would just be
the microversion of the API I'm talking to.

__
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

Re: [openstack-dev] Version header for OpenStack microversion support

2016-06-20 Thread Jamie Lennox 
On 21 June 2016 at 11:41, Edward Leafe  wrote:

> On Jun 18, 2016, at 9:03 AM, Clint Byrum  wrote:
>
> > Whatever API version is used behind the compute API is none of the user's
> > business.
>
> Actually, yeah, it is.
>
> If I write an app or a tool that expects to send information in a certain
> format, and receive responses in a certain format, I don't want that to
> change when the cloud operator upgrades their system. I only want things to
> change when I specifically request that they change by specifying a new
> microversion.
>
>
I think the point there was as a user you only get to specify the version
you communicate with the initial service. Talking to nova you can ask for
2.4 (no idea on the actual numbers), but you have no control over the
version nova uses to talk to neutron or glance because that doesn't affect
the output to you as a user.


>
> -- Ed Leafe
>
>
>
>
>
>
> __
> 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
>
>
__
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

Re: [openstack-dev] Version header for OpenStack microversion support

2016-06-20 Thread Edward Leafe 
On Jun 18, 2016, at 9:03 AM, Clint Byrum  wrote:

> Whatever API version is used behind the compute API is none of the user's
> business.

Actually, yeah, it is.

If I write an app or a tool that expects to send information in a certain 
format, and receive responses in a certain format, I don't want that to change 
when the cloud operator upgrades their system. I only want things to change 
when I specifically request that they change by specifying a new microversion.


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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

Re: [openstack-dev] Version header for OpenStack microversion support

2016-06-20 Thread D'Angelo, Scott 
FYI, Cinder implemented using the style recommended by the API-wg:

https://review.openstack.org/#/c/224910


From: Sean Dague <s...@dague.net>
Sent: Monday, June 20, 2016 6:32:10 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Version header for OpenStack microversion support

On 06/18/2016 06:32 AM, Jamie Lennox wrote:
> Quick question: why do we need the service type or name in there? You
> really should know what API you're talking to already and it's just
> something that makes it more difficult to handle all the different APIs
> in a common way.

It is also extremely useful in wire interactions to be explicit so that
you know for sure you are interacting with the thing you think you are.
There was also the potential question of compound API operations (a Nova
call that calls other microversioned services that may impact
representation) and whether that may need to be surfaced to the user.
For instance network portions of the 'servers' object may get impacted
by Neutron.

With all those possibilities, putting in the extra ~8 bytes to handle
contingencies seemed prudent.

-Sean

--
Sean Dague
http://dague.net

__
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

__
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

Re: [openstack-dev] Version header for OpenStack microversion support

2016-06-20 Thread Sean Dague 
On 06/18/2016 06:32 AM, Jamie Lennox wrote:
> Quick question: why do we need the service type or name in there? You
> really should know what API you're talking to already and it's just
> something that makes it more difficult to handle all the different APIs
> in a common way.

It is also extremely useful in wire interactions to be explicit so that
you know for sure you are interacting with the thing you think you are.
There was also the potential question of compound API operations (a Nova
call that calls other microversioned services that may impact
representation) and whether that may need to be surfaced to the user.
For instance network portions of the 'servers' object may get impacted
by Neutron.

With all those possibilities, putting in the extra ~8 bytes to handle
contingencies seemed prudent.

-Sean

-- 
Sean Dague
http://dague.net

__
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

Re: [openstack-dev] Version header for OpenStack microversion support

2016-06-18 Thread Steve Martinelli 
Recapping...

- ensure we are not using X- in the header
- use the service type, not name

For keystone it would be: OpenStack-API-Version: identity 3.7
For nova it would be: OpenStack-API-Version: compute 2.27
  (which matches what is proposed here:
https://review.openstack.org/#/c/300077/14/api-guide/source/microversions.rst
)

Similarly for manila and ironic, I don't have the links handy, or the what
the headers are currently

On Sat, Jun 18, 2016 at 11:13 AM, Ravi, Goutham <goutham.r...@netapp.com>
wrote:

> True, manila is currently using the same header; but given that nova and
> ironic are supporting the new header recommendation, this has come up for
> discussion in the manila community.
>
>
>
> In any case, the use of the prefix “X-“, and project names within the
> header is not recommended. Please refer to the API Working Group’s
> recommendation in this regard:
>
>
>
>
> http://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html
>
>
>
> The example already suggests what needs to be done in case of the identity
> project J
>
>
>
> --
>
> Goutham
>
>
>
> *From: *Steve Martinelli <s.martine...@gmail.com>
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" <openstack-dev@lists.openstack.org>
> *Date: *Saturday, June 18, 2016 at 6:22 AM
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] Version header for OpenStack microversion
> support
>
>
>
> Looks like Manila is using the service name instead of type
> (X-OpenStack-Manila-API-Version) according to this link anyway:
> http://docs.openstack.org/developer/manila/devref/api_microversion_dev.html
>
> Keystone can follow the cross project spec and use the service type
> (Identity instead of Keystone).
>
> On Jun 17, 2016 12:44 PM, "Ed Leafe" <e...@leafe.com> wrote:
>
> On Jun 17, 2016, at 11:29 AM, Henry Nash <henryna...@mac.com> wrote:
>
> > We are currently in the process of implementing microversion support in
> keystone - and are obviously trying to follow the cross-projec spec for
> this (
> http://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html
> ).
> >
> > One thing I noticed was that the header specified in this spec is of the
> form:
> >
> > OpenStack-API-Version: [SERVICE_TYPE] [X,Y]
> >
> > for example:
> >
> > OpenStack-API-Version: identity 3.7
> >
> > However, from what i can see of the current implementations I have seen
> of microversioning in OpenStack (Nova, Manilla), they use service-specific
> headers, e.g.
> >
> > X-OpenStack-Nova-API-Version: 2.12
> >
> > My question is whether there a plan to converge on the generalized
> header format….or are we keep with the service-specific headers? I’d
> obviously like to implement the correct one for keystone.
>
> Yes, the plan is to converge on the more generic headers. The Nova headers
> (don’t know about Manilla) pre-date the API WG spec, and were the
> motivation for development of that spec. We’ve even made it possible to
> accept both header formats [0] until things can be migrated to the
> recommended format.
>
> [0] https://review.openstack.org/#/c/300077/
>
> -- Ed Leafe
>
>
>
>
>
>
> __
> 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
>
>
> __
> 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
>
>
__
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

Re: [openstack-dev] Version header for OpenStack microversion support

2016-06-18 Thread Ravi, Goutham 
True, manila is currently using the same header; but given that nova and ironic 
are supporting the new header recommendation, this has come up for discussion 
in the manila community.

In any case, the use of the prefix “X-“, and project names within the header is 
not recommended. Please refer to the API Working Group’s recommendation in this 
regard:

http://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html

The example already suggests what needs to be done in case of the identity 
project ☺

--
Goutham

From: Steve Martinelli <s.martine...@gmail.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Saturday, June 18, 2016 at 6:22 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] Version header for OpenStack microversion support


Looks like Manila is using the service name instead of type 
(X-OpenStack-Manila-API-Version) according to this link anyway: 
http://docs.openstack.org/developer/manila/devref/api_microversion_dev.html

Keystone can follow the cross project spec and use the service type (Identity 
instead of Keystone).
On Jun 17, 2016 12:44 PM, "Ed Leafe" <e...@leafe.com<mailto:e...@leafe.com>> 
wrote:
On Jun 17, 2016, at 11:29 AM, Henry Nash 
<henryna...@mac.com<mailto:henryna...@mac.com>> wrote:

> We are currently in the process of implementing microversion support in 
> keystone - and are obviously trying to follow the cross-projec spec for this 
> (http://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html).
>
> One thing I noticed was that the header specified in this spec is of the form:
>
> OpenStack-API-Version: [SERVICE_TYPE] [X,Y]
>
> for example:
>
> OpenStack-API-Version: identity 3.7
>
> However, from what i can see of the current implementations I have seen of 
> microversioning in OpenStack (Nova, Manilla), they use service-specific 
> headers, e.g.
>
> X-OpenStack-Nova-API-Version: 2.12
>
> My question is whether there a plan to converge on the generalized header 
> format….or are we keep with the service-specific headers? I’d obviously like 
> to implement the correct one for keystone.

Yes, the plan is to converge on the more generic headers. The Nova headers 
(don’t know about Manilla) pre-date the API WG spec, and were the motivation 
for development of that spec. We’ve even made it possible to accept both header 
formats [0] until things can be migrated to the recommended format.

[0] https://review.openstack.org/#/c/300077/

-- Ed Leafe






__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
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

Re: [openstack-dev] Version header for OpenStack microversion support

2016-06-18 Thread Chris Dent 

On Sat, 18 Jun 2016, Jamie Lennox wrote:


Quick question: why do we need the service type or name in there? You
really should know what API you're talking to already and it's just
something that makes it more difficult to handle all the different APIs in
a common way.


The basic idea is so that it is possible to write generic client code
that has a header with a specific name and purpose that can have a
value that works for multiple services and can be coded and talked
about in a generic way.

So in fact the reason the change is a good thing is exactly what you
say: The old way makes it more difficult to handle things in a common
way because you have to seek out lots of different headers. The library
referenced below lets you:

   version = microversion_parse.get_version(headers, service_type='compute')

and get back either the compute microversion, None or an error. Do it
again with 'identity' get back the identity microversion. Etc.

Another point: the old version of the header had "value" information on
both sides of the name value pair. The new version is more general.

Bonus for the lazy at heart (a virtue!): a client can send version
headers for every service being addressed in a suite of tasks in one
fell swoop.

And finally, we knew we needed to update the microversion headers to
get rid of two things which are deprecated:

* using 'X-' on headers
* referring to services by their project name when we should be using
  their service type

So if that change was going to be made anyway, and we wanted to avoid
having lots of miscellaneous headers (see proliferation guideline
below), may as well lump several changes to avoid too much churn and
have a tidy future.

Some potentially useful links:

* a library for parsing various microversion headers out of a variety of
  header representations:
  https://pypi.python.org/pypi/microversion_parse

* header non proliferation guideline:
  
http://specs.openstack.org/openstack/api-wg/guidelines/headers.html#avoid-proliferating-headers

* adding support for the new style to nova:
  * the spec
  
http://specs.openstack.org/openstack/nova-specs/specs/newton/approved/modern-microversions.html
  * nova itself (as I think it was Ed has already pointed out)
  https://review.openstack.org/#/c/300077/
  * novaclient
  https://review.openstack.org/#/c/323362/

I hope some of that is useful.

--
Chris Dent   (╯°□°)╯︵┻━┻http://anticdent.org/
freenode: cdent tw: @anticdent__
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

Re: [openstack-dev] Version header for OpenStack microversion support

2016-06-18 Thread Clint Byrum 
Excerpts from Henry Nash's message of 2016-06-18 13:14:17 +0100:
> > On 18 Jun 2016, at 11:32, Jamie Lennox  wrote:
> > 
> > Quick question: why do we need the service type or name in there? You 
> > really should know what API you're talking to already and it's just 
> > something that makes it more difficult to handle all the different APIs in 
> > a common way.
> >

< moved question to be inline for readability>

> …I think it is so you can have a header in a request that, once issued, can 
> be passed for service to service, e.g.:
> 
> OpenStack-API-Version: identity 3.7, compute 2.11
>

Whatever API version is used behind the compute API is none of the user's
business. Nova will support whatever identity API versions it supports,
and if you've passed it something that isn't compatible with the APIs it
knows how to speak, asking for it to support a version that it doesn't
isn't going to change the fact that this is an impossible request already.

That said, I kind of like the idea of specifying the name there for the
one API you are speaking, just in case something goes awry and you try
to send an identity request to compute, it's more clear that this is the
wrong API you're talking to. It's not like it's hard to split a string
on white space.

__
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

Re: [openstack-dev] Version header for OpenStack microversion support

2016-06-18 Thread Henry Nash 
…I think it is so you can have a header in a request that, once issued, can be 
passed for service to service, e.g.:

OpenStack-API-Version: identity 3.7, compute 2.11

Henry

> On 18 Jun 2016, at 11:32, Jamie Lennox  wrote:
> 
> Quick question: why do we need the service type or name in there? You really 
> should know what API you're talking to already and it's just something that 
> makes it more difficult to handle all the different APIs in a common way.
> 
> On Jun 18, 2016 8:25 PM, "Steve Martinelli"  > wrote:
> Looks like Manila is using the service name instead of type 
> (X-OpenStack-Manila-API-Version) according to this link anyway: 
> http://docs.openstack.org/developer/manila/devref/api_microversion_dev.html 
> 
> Keystone can follow the cross project spec and use the service type (Identity 
> instead of Keystone).
> 
> On Jun 17, 2016 12:44 PM, "Ed Leafe" > 
> wrote:
> On Jun 17, 2016, at 11:29 AM, Henry Nash  > wrote:
> 
> > We are currently in the process of implementing microversion support in 
> > keystone - and are obviously trying to follow the cross-projec spec for 
> > this 
> > (http://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html
> >  
> > ).
> >
> > One thing I noticed was that the header specified in this spec is of the 
> > form:
> >
> > OpenStack-API-Version: [SERVICE_TYPE] [X,Y]
> >
> > for example:
> >
> > OpenStack-API-Version: identity 3.7
> >
> > However, from what i can see of the current implementations I have seen of 
> > microversioning in OpenStack (Nova, Manilla), they use service-specific 
> > headers, e.g.
> >
> > X-OpenStack-Nova-API-Version: 2.12
> >
> > My question is whether there a plan to converge on the generalized header 
> > format….or are we keep with the service-specific headers? I’d obviously 
> > like to implement the correct one for keystone.
> 
> Yes, the plan is to converge on the more generic headers. The Nova headers 
> (don’t know about Manilla) pre-date the API WG spec, and were the motivation 
> for development of that spec. We’ve even made it possible to accept both 
> header formats [0] until things can be migrated to the recommended format.
> 
> [0] https://review.openstack.org/#/c/300077/ 
> 
> 
> -- Ed Leafe
> 
> 
> 
> 
> 
> 
> __
> 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 
> 
> 
> __
> 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 
> 
> 
> __
> 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

__
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

Re: [openstack-dev] Version header for OpenStack microversion support

2016-06-18 Thread Jamie Lennox 
Quick question: why do we need the service type or name in there? You
really should know what API you're talking to already and it's just
something that makes it more difficult to handle all the different APIs in
a common way.
On Jun 18, 2016 8:25 PM, "Steve Martinelli"  wrote:

> Looks like Manila is using the service name instead of type
> (X-OpenStack-Manila-API-Version) according to this link anyway:
> http://docs.openstack.org/developer/manila/devref/api_microversion_dev.html
>
> Keystone can follow the cross project spec and use the service type
> (Identity instead of Keystone).
> On Jun 17, 2016 12:44 PM, "Ed Leafe"  wrote:
>
>> On Jun 17, 2016, at 11:29 AM, Henry Nash  wrote:
>>
>> > We are currently in the process of implementing microversion support in
>> keystone - and are obviously trying to follow the cross-projec spec for
>> this (
>> http://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html
>> ).
>> >
>> > One thing I noticed was that the header specified in this spec is of
>> the form:
>> >
>> > OpenStack-API-Version: [SERVICE_TYPE] [X,Y]
>> >
>> > for example:
>> >
>> > OpenStack-API-Version: identity 3.7
>> >
>> > However, from what i can see of the current implementations I have seen
>> of microversioning in OpenStack (Nova, Manilla), they use service-specific
>> headers, e.g.
>> >
>> > X-OpenStack-Nova-API-Version: 2.12
>> >
>> > My question is whether there a plan to converge on the generalized
>> header format….or are we keep with the service-specific headers? I’d
>> obviously like to implement the correct one for keystone.
>>
>> Yes, the plan is to converge on the more generic headers. The Nova
>> headers (don’t know about Manilla) pre-date the API WG spec, and were the
>> motivation for development of that spec. We’ve even made it possible to
>> accept both header formats [0] until things can be migrated to the
>> recommended format.
>>
>> [0] https://review.openstack.org/#/c/300077/
>>
>> -- Ed Leafe
>>
>>
>>
>>
>>
>>
>> __
>> 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
>>
>
> __
> 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
>
>
__
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

Re: [openstack-dev] Version header for OpenStack microversion support

2016-06-18 Thread Steve Martinelli 
Looks like Manila is using the service name instead of type
(X-OpenStack-Manila-API-Version) according to this link anyway:
http://docs.openstack.org/developer/manila/devref/api_microversion_dev.html

Keystone can follow the cross project spec and use the service type
(Identity instead of Keystone).
On Jun 17, 2016 12:44 PM, "Ed Leafe"  wrote:

> On Jun 17, 2016, at 11:29 AM, Henry Nash  wrote:
>
> > We are currently in the process of implementing microversion support in
> keystone - and are obviously trying to follow the cross-projec spec for
> this (
> http://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html
> ).
> >
> > One thing I noticed was that the header specified in this spec is of the
> form:
> >
> > OpenStack-API-Version: [SERVICE_TYPE] [X,Y]
> >
> > for example:
> >
> > OpenStack-API-Version: identity 3.7
> >
> > However, from what i can see of the current implementations I have seen
> of microversioning in OpenStack (Nova, Manilla), they use service-specific
> headers, e.g.
> >
> > X-OpenStack-Nova-API-Version: 2.12
> >
> > My question is whether there a plan to converge on the generalized
> header format….or are we keep with the service-specific headers? I’d
> obviously like to implement the correct one for keystone.
>
> Yes, the plan is to converge on the more generic headers. The Nova headers
> (don’t know about Manilla) pre-date the API WG spec, and were the
> motivation for development of that spec. We’ve even made it possible to
> accept both header formats [0] until things can be migrated to the
> recommended format.
>
> [0] https://review.openstack.org/#/c/300077/
>
> -- Ed Leafe
>
>
>
>
>
>
> __
> 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
>
__
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

Re: [openstack-dev] Version header for OpenStack microversion support

2016-06-17 Thread Ed Leafe 
On Jun 17, 2016, at 11:29 AM, Henry Nash  wrote:

> We are currently in the process of implementing microversion support in 
> keystone - and are obviously trying to follow the cross-projec spec for this 
> (http://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html).
>  
> 
> One thing I noticed was that the header specified in this spec is of the form:
> 
> OpenStack-API-Version: [SERVICE_TYPE] [X,Y]
> 
> for example:
> 
> OpenStack-API-Version: identity 3.7
> 
> However, from what i can see of the current implementations I have seen of 
> microversioning in OpenStack (Nova, Manilla), they use service-specific 
> headers, e.g.
> 
> X-OpenStack-Nova-API-Version: 2.12
> 
> My question is whether there a plan to converge on the generalized header 
> format….or are we keep with the service-specific headers? I’d obviously like 
> to implement the correct one for keystone.

Yes, the plan is to converge on the more generic headers. The Nova headers 
(don’t know about Manilla) pre-date the API WG spec, and were the motivation 
for development of that spec. We’ve even made it possible to accept both header 
formats [0] until things can be migrated to the recommended format.

[0] https://review.openstack.org/#/c/300077/

-- Ed Leafe






__
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

[openstack-dev] Version header for OpenStack microversion support

2016-06-17 Thread Henry Nash 
Hi

We are currently in the process of implementing microversion support in 
keystone - and are obviously trying to follow the cross-projec spec for this 
(http://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html
 
).
 

One thing I noticed was that the header specified in this spec is of the form:

OpenStack-API-Version: [SERVICE_TYPE] [X,Y]

for example:

OpenStack-API-Version: identity 3.7

However, from what i can see of the current implementations I have seen of 
microversioning in OpenStack (Nova, Manilla), they use service-specific 
headers, e.g.

X-OpenStack-Nova-API-Version: 2.12

My question is whether there a plan to converge on the generalized header 
format….or are we keep with the service-specific headers? I’d obviously like to 
implement the correct one for keystone.

Thanks

Henry





__
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