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 <mru...@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-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