Open Stack

Thanks Bob.

Two answers/comments below.

On 6 May 2015 at 14:59, Bob Melander (bmelande) <bmelande at cisco.com> wrote:

>  Hi Salvatore,
>
>  Two questions/remarks below.
>
>   From: Salvatore Orlando <sorlando at nicira.com>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> Date: onsdag 6 maj 2015 00:13
> To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [neutron][api] Extensions out, Micro-versions in
>
>   #5 Plugin/Vendor specific APIs
>
>  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.
> 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.
> The current proposal still allows 3rd parties to attach extensions to the
> neutron API, provided that:
> - they're not considered part of the Neutron API, in terms of versioning,
> documentation, and client support
>
>  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>.
> 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.
>

In a nutshell no, but maybe.
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.
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.
However the developer, user, and operator community might have a different
opinion, and as usual the decision will derive from community consensus.


>
>    - they do not redefine resources defined by the Neutron API.
>
>  BOB> Does “redefine" here include extending a resource with additional
> attributes?
>

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.


>    - they do not live in the neutron source tree
> The aim of the provisions above is to minimize the impact of such
> extensions on API portability.
>
>  Thanks for reading and thanks in advance for your feedback,
>  Salvatore
>
>  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)
>
>  [1] https://review.openstack.org/#/c/136760/
> [2]
> http://a.espncdn.com/combiner/i/?img=/photo/2015/0502/fc-banner-jd-1296x729.jpg&w=738&site=espnfc
> [3]
> http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/api-microversions.html
> [4] By "vendor" here we refer either to a cloud provider or a company
> providing Neutron integration for their products.
>
> __________________________________________________________________________
> 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/20150506/e08a68a7/attachment.html>