[openstack-dev] [heat][horizon] Backward-incompatible changes to the Neutron API
Paul Michali
pc at michali.net
Thu Aug 27 15:38:23 UTC 2015
Akihiro, can you look at the developer's reference I posted (191944), where
there is the overall API plan and a proposal for handling backward
compatibility.
Thanks!
Paul Michali (pc_m)
On Thu, Aug 27, 2015 at 11:12 AM Akihiro Motoki <amotoki at gmail.com> wrote:
> As Mathias said, Horizon worked (and in many cases works) cross releases.
>
> Horizon determines supported features based on keystone catalogs,
> extension list from back-end services (like nova, neutron).
> Micro-versioning support may come in future (though it is not supported).
>
> For backward incompatible API change in VPNaaS, Horizon can determine
> if Neutron (including VPNaaS) provides a way to determines which version
> is available.
> At now, the only way is to expose it through the extension list.
>
> On the other hand, it is tough to maintain multiple versions of
> implementations.
> It is reasonable to me that Horizon supports two implementation in one or
> two
> release cycle(s) and drop older implementation later.
>
> Akihiro
>
>
> 2015-08-27 16:29 GMT+09:00 Matthias Runge <mrunge at redhat.com>:
>
>> On 26/08/15 23:55, James Dempsey wrote:
>> > Greetings Heat/Horizon Devs,
>> >
>> > There is some talk about possibly backward-incompatible changes to the
>> > Neutron VPNaaS API and I'd like to better understand what that means for
>> > Heat and Horizon.
>> >
>> > It has been proposed to change Neutron VPNService objects such that they
>> > reference a new resource type called an "Endpoint Group" instead of
>> > simply a Subnet.
>> >
>> > Does this mean that any version of Heat/Horizon would only be able to
>> > support either the old or new Neutron API, or is there some way to allow
>> > a version of Heat/Horizon to support both?
>> >
>> In the past, Horizon worked cross releases.
>>
>> The way horizon works is, it looks out for a networking endpoint in
>> keystone catalog. We don't really care, if it's nova or neutron
>> answering. The rest should be discoverable via API.
>> Horizon uses neutronclient rather than directly talking to neutron by
>> using its API interface.
>>
>> If you make it discoverable, and you'd add that to neutronclient,
>> horizon could support both.
>>
>> Matthias
>>
>>
>>
>>
>> __________________________________________________________________________
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150827/bd117a38/attachment.html>
More information about the OpenStack-dev
mailing list