<div dir="ltr">Thanks Bob.<div><br></div><div>Two answers/comments below.<br><div class="gmail_extra"><br><div class="gmail_quote">On 6 May 2015 at 14:59, Bob Melander (bmelande) <span dir="ltr"><<a href="mailto:bmelande@cisco.com" target="_blank">bmelande@cisco.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div>Hi Salvatore,</div>
<div><br>
</div>
<div>Two questions/remarks below.</div>
<div><br>
</div>
<span>
<div style="font-family:Calibri;font-size:11pt;text-align:left;color:black;BORDER-BOTTOM:medium none;BORDER-LEFT:medium none;PADDING-BOTTOM:0in;PADDING-LEFT:0in;PADDING-RIGHT:0in;BORDER-TOP:#b5c4df 1pt solid;BORDER-RIGHT:medium none;PADDING-TOP:3pt">
<span style="font-weight:bold">From: </span>Salvatore Orlando <<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>><br>
<span style="font-weight:bold">Reply-To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span>onsdag 6 maj 2015 00:13<br>
<span style="font-weight:bold">To: </span>OpenStack Development Mailing List <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><span class=""><br>
<span style="font-weight:bold">Subject: </span>[openstack-dev] [neutron][api] Extensions out, Micro-versions in<br>
</span></div><span class="">
<div><br>
</div>
<div>
<div>
<div dir="ltr">
<div>#5 Plugin/Vendor specific APIs</div>
<div><br>
</div>
<div>Neutron is without doubt the project with the highest number of 3rd party (OSS and commercial) integration. After all it was mostly vendors who started this project.</div>
<div>Vendors [4] use the extension mechanism to expose features in their products not covered by the Neutron API or to provide some sort of value-added service.</div>
<div>The current proposal still allows 3rd parties to attach extensions to the neutron API, provided that:</div>
<div>- they're not considered part of the Neutron API, in terms of versioning, documentation, and client support</div>
</div>
</div>
</div>
</span></span>
<div><br>
</div>
<div>BOB> There are today vendor specific commands in the Neutron CLI client. Such commands are prepended with the name of the vendor, like cisco_<command> and nec_<command>.</div>
<div>I think that makes it quite visible to the user that the command is specific to a vendor feature and not part of neutron core. Would it be possible to allow for that also going forward? I would think that from a user perspective it can be convenient to
 be able to access vendor add-on features using a single CLI client.</div></div></blockquote><div><br></div><div>In a nutshell no, but maybe.</div><div>Vendor extensions are not part of the Neutron API, but if the community decides to support them in the official client anyway, you will still be able to run vendor-specific CLI commands. Otherwise vendors will have to provide their own client tools, which is feasible as well.</div><div>Personally, I would be against having vendor-specific CLI commands in python-neutronclient. To me it will be tantamount to saying: yes please do versioning, but don't take extensions away from us.</div><div>However the developer, user, and operator community might have a different opinion, and as usual the decision will derive from community consensus.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif"><span class="">
<div><br>
</div>
<span>
<div>
<div>
<div dir="ltr">
<div>- they do not redefine resources defined by the Neutron API.</div>
</div>
</div>
</div>
</span>
<div><br>
</div>
</span><div>BOB> Does “redefine" here include extending a resource with additional attributes?</div></div></blockquote><div><br></div><div>In my opinion yes. But I do not have a very strong point here. Also, enforcing this will require many vendors to do backward incompatible changes in the API, and therefore we would need a deprecation cycle. So let's say that ideally modifying the shape of neutron resource by adding attributes, might be considered a "discouraged, but not forbidden" practice. For instance if you want to attach a qos profile to a port rather then adding a 'vendor_qos_profile' to the port resource you might add a vendor_port_info resource with a reference to the vendor_qos_profile_id and the neutron port_id.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif"><span class="">
<div><br>
</div>
<span>
<div>
<div>
<div dir="ltr">
<div>- they do not live in the neutron source tree</div>
<div>The aim of the provisions above is to minimize the impact of such extensions on API portability.</div>
<div><br>
</div>
<div>Thanks for reading and thanks in advance for your feedback,<br>
</div>
<div>Salvatore</div>
<div><br>
</div>
<div>The title of this post has been inspired by [2]  (the message in the banner may be unintelligible to readers not fluent in european football)<br>
</div>
<div><br>
</div>
[1] <a href="https://review.openstack.org/#/c/136760/" target="_blank">https://review.openstack.org/#/c/136760/</a>
<div>[2] <a href="http://a.espncdn.com/combiner/i/?img=/photo/2015/0502/fc-banner-jd-1296x729.jpg&w=738&site=espnfc" target="_blank">http://a.espncdn.com/combiner/i/?img=/photo/2015/0502/fc-banner-jd-1296x729.jpg&w=738&site=espnfc</a></div>
<div>[3] <a href="http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/api-microversions.html" target="_blank">http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/api-microversions.html</a></div>
<div>[4] By "vendor" here we refer either to a cloud provider or a company providing Neutron integration for their products.</div>
</div>
</div>
</div>
</span>
</span></div>

<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div></div>