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)
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
…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
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 mo
Thanks, folks! I will do my best!
Regards,
Zhu Rong__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/
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
On Fri, Jun 17, 2016 at 08:23:05PM +, Jay Faulkner wrote:
> +1 lets get it voting. Feel free to add me as a reviewer to the
> project-config patch to make the change if you want me to vote officially :).
Agree. I did the thing :)
https://review.openstack.org/#/c/331422/1
// jim
>
>
> Tha
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
On Thu, Jun 16, 2016 at 11:12:31AM -0400, Jim Rollenhagen wrote:
> Hi all,
>
> I'd like to propose Jay Faulkner (JayF) and Sam Betts (sambetts) for the
> ironic-core team.
>
> Jay has been in the community as long as I have, has been IPA and
> ironic-specs core for quite some time. His background
Got your mail late. It is OK, Have a nice weekend. I will send meet minutes
after meeting.
On Jun 17, 2016 12:26 PM, "Jaivish Kothari" <
janonymous.codevult...@gmail.com> wrote:
> Hi Daisy Team,
>
> It is my honor to become a part of team,Unfortunately i had to leave the
> town for Client meeting
On 23:53 Jun 17, Matthew Treinish wrote:
> On Fri, Jun 17, 2016 at 04:26:49PM -0700, Mike Perez wrote:
> > On 15:12 Jun 14, Matthew Treinish wrote:
> > > I don't think backwards compatibility policies really apply to what what
> > > define
> > > as the set of tests that as a community we are sa
On 6/14/2016 6:19 PM, Chris Hoge wrote:
One would hope that micro-versions would be able to address this exact
issue for vendors by giving them a means to propose optional but
well-defined API response additions (not extensions) that are defined
upstream and usable by all vendors. If it’s not too
On 6/14/2016 6:37 PM, Chris Hoge wrote:
I’m beginning to wonder if we need to make DefCore use release
branches then back-port bug-fixes and relevant features additions
as necessary.
To clarify, do you mean use release branches from the upstream repos?
Because if DefCore is supporting 2 years
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-g
14 matches
Mail list logo
