<div dir="ltr">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.<div><br></div><div>Thanks!</div><div><br></div><div>Paul Michali (pc_m)</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Aug 27, 2015 at 11:12 AM Akihiro Motoki <<a href="mailto:amotoki@gmail.com">amotoki@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">As Mathias said, Horizon worked (and in many cases works) cross releases.<div><br></div><div>Horizon determines supported features based on keystone catalogs,<br></div><div>extension list from back-end services (like nova, neutron).</div><div>Micro-versioning support may come in future (though it is not supported).</div><div><br></div><div>For backward incompatible API change in VPNaaS, Horizon can determine</div><div>if Neutron (including VPNaaS) provides a way to determines which version is available.</div><div>At now, the only way is to expose it through the extension list.</div><div><br></div><div>On the other hand, it is tough to maintain multiple versions of implementations.</div><div>It is reasonable to me that Horizon supports two implementation in one or two</div><div>release cycle(s) and drop older implementation later.</div></div><div dir="ltr"><div><br></div><div>Akihiro<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-08-27 16:29 GMT+09:00 Matthias Runge <span dir="ltr"><<a href="mailto:mrunge@redhat.com" target="_blank">mrunge@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 26/08/15 23:55, James Dempsey wrote:<br>
> Greetings Heat/Horizon Devs,<br>
><br>
> There is some talk about possibly backward-incompatible changes to the<br>
> Neutron VPNaaS API and I'd like to better understand what that means for<br>
> Heat and Horizon.<br>
><br>
> It has been proposed to change Neutron VPNService objects such that they<br>
> reference a new resource type called an "Endpoint Group" instead of<br>
> simply a Subnet.<br>
><br>
> Does this mean that any version of Heat/Horizon would only be able to<br>
> support either the old or new Neutron API, or is there some way to allow<br>
> a version of Heat/Horizon to support both?<br>
><br>
</span>In the past, Horizon worked cross releases.<br>
<br>
The way horizon works is, it looks out for a networking endpoint in<br>
keystone catalog. We don't really care, if it's nova or neutron<br>
answering. The rest should be discoverable via API.<br>
Horizon uses neutronclient rather than directly talking to neutron by<br>
using its API interface.<br>
<br>
If you make it discoverable, and you'd add that to neutronclient,<br>
horizon could support both.<br>
<span><font color="#888888"><br>
Matthias<br>
</font></span><div><div><br>
<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>