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 <cl...@fewbar.com> 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
