Re: [openstack-dev] [heat][horizon] Backward-incompatible changes to the Neutron API
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 amot...@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 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 __ 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
Re: [openstack-dev] [heat][horizon] Backward-incompatible changes to the Neutron API
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
Re: [openstack-dev] [heat][horizon] Backward-incompatible changes to the Neutron API
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
Re: [openstack-dev] [heat][horizon] Backward-incompatible changes to the Neutron API
For details on the API/resource change, see the developer's reference document that is under review: https://review.openstack.org/#/c/191944/ There is a section at the end, where I'm proposing a possible way to support both versions of the API and provide backward compatibility. Feel free to comment on the review. Regards, Paul Michali (pc_m) On Wed, Aug 26, 2015 at 6:10 PM James Dempsey jam...@catalyst.net.nz 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? Thanks, James -- James Dempsey Senior Cloud Engineer Catalyst IT Limited +64 4 803 2264 -- __ 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
