[openstack-dev] [api][nova][ironic] Microversion API HTTP header

Jay Pipes jaypipes at gmail.com
Sun Jul 5 15:45:04 UTC 2015


On 06/25/2015 02:19 PM, Monty Taylor wrote:
> On 06/25/2015 01:35 PM, Devananda van der Veen wrote:
>> Sean's point and Dmitri's are similar.
>>
>> There are APIs for projects which do not have official team or "program"
>> names. And some teams may produce more than one forward-facing service.
>> Naming the API based in the team name doesn't make sense.
>>
>> My previous point is that restricting the API name to the team/program name
>> will prevent any competition among projects. It'll be impossibly confusing
>> to users if more than one "monitoring" project exists, they all have
>> different API, but each claim to be the one true OpenStack-Monitoring-API
>
> I believe that it is important that there is only one api in OpenStack
> that provides a given short name. Even with the big tent.

So do I. I've been saying that for quite some time. Which is why I've 
been arguing for referring to things like they are referred to on the 
API documentation site:

http://developer.openstack.org/#api

By the name of the API, which is "The OpenStack Compute API", not "The 
Nova API".

> I say that because, as a user, I ask the service catalog for a well
> known service type - "compute" or "baremetal" or "network" - and I get
> back a REST endpoint that is ostensibly for that purpose.

Precisely correct.

> If I then have to introspect that service to find out what it really is,
> we have fully jumped the shark and started prioritizing our own
> navel-gazing over any hope of any human ever using what we're doing.
>
> So - yes, this is potentially, although not actually, a problem right
> now. And we need to solve it before it moves from being an actual problem.

Right. Which is why I was trying to prevent this problem from becoming 
bigger than it needs to be, and trying to convince people to use the 
service type that appears in the Keystone Service Catalog as the {NAME} 
in X-OpenStack-{NAME}-API-Version header.

Best,
-jay

>> On Jun 25, 2015 9:37 AM, "Sean Dague" <sean at dague.net> wrote:
>>
>>> On 06/25/2015 12:04 PM, Anne Gentle wrote:
>>>>
>>>>
>>>> On Thu, Jun 25, 2015 at 10:55 AM, Dmitry Tantsur <dtantsur at redhat.com
>>>> <mailto:dtantsur at redhat.com>> wrote:
>>> <snip>
>>>>
>>>>
>>>>      I'm not sure where the assumption comes from that people will know
>>>>      "compute" better than "nova".
>>>>
>>>>
>>>> I have been supporting developer end users on the Rackspace cloud for
>>>> nearly four years now. I gave a talk in Paris at the Summit about
>>>> supporting developers. Developers using cloud resources expect to use
>>>> computing power or storage capacity to accomplish a broader task. Nova
>>>> and swift have nothing to do with their expectations.
>>>
>>> That's good feedback, and clearly moves the needle in my head.
>>>
>>> It also does open up a question about the big tent nature, because it's
>>> unclear what projects that do not yet have a generic name allocated to
>>> them would use.
>>>
>>>          -Sean
>>>
>>> --
>>> Sean Dague
>>> http://dague.net
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



More information about the OpenStack-dev mailing list