yahoo-eng-team team mailing list archive

[Brian Curtin <brian@xxxxxxxxxx>]

** Changed in: python-openstacksdk
       Status: New => Won't Fix

** No longer affects: python-openstacksdk

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1705755

Title:
  [RFE] Plugin support for API resource attribute extensions

Status in neutron:
  Triaged
Status in python-openstackclient:
  New

Bug description:
  FORWARD
  ---------------
  The purpose of this bug is to facilitate a discussion. While I'm willing to do all the work to implement the feature request herein, I'd first like some agreement that:
  - We want to solve this problem.
  - Core(s) on the respective projects (python-openstackclient and python-openstacksdk) are willing to provide some guidance on the best high-level approach.

  
  BACKGROUND
  ----------------------
  Some OpenStack REST APIs such as neutron and nova support API extensions.
  While the implementation details for API extensions may differ from project to project, the basic extension support across all projects includes the ability for pluggable extensions to augment the REST API in the following ways:
  (a) Introducing new RESTful resources (APIs). These may be new top-level resources (e.g. /v1/theapi/{extension_resource}) or sub-resources (e.g. /v1/theapi/existing_resource/{extension_subresource}).
  (b) Adding new attributes (fields) to existing RESTful resources. For example neutron's net-mtu extension adds a 'mtu' attribute to networks [1] and nova's extended status adds attributes to servers [2].

  While some API extensions may exist in-tree (e.g. right in neutron or
  nova), they can also live in out-of-tree projects that implement
  plugins/drivers/etc..

  Hopefully we can all agree that a CLI should encompass the means to
  support both #a and #b above in some form or another in order to
  obtain the pluggability our consumers expect with OpenStack.


  PROBLEM DESCRIPTION
  ------------------------------------
  For sake of argument lets consider #a and #b as use cases from an OpenStack CLI (python-openstackclient and python-openstacksdk) perspective. Albeit we are talking from a contributor perspective here; but the ability to contribute drive features users can consume.

  (a) This case should already be supported via the existing OSC plugin
  model. For example [3].

  (b) This case is covered for stadium projects; they can add logic
  right into python-openstackclient[sdk] as needed. However for non-
  stadium projects, this case is not covered; today there's no easy way
  to extend existing OSC resources/actions/options/etc. in a reusable
  manner. For example, suppose a non-stadium neutron (plugin) project
  implements the network API, extends the network resource with
  additional attribute(s) and wants to provide CLI support for these
  attributes. Ideally they should be able to reuse the existing neutron
  network OSC logic in a pluggable manner such that they need not
  reimplement the OSC "actions" and associated logic.

  From a technical perspective, case #b roughly requires the ability for non-stadium projects (with such attribute extensions) to:
  (1) Add attributes to python-openstacksdk resource(s). This allows the extension attributes to be "collected" from an API response body.
  (2) Extend existing python-openstackclient commands by;
   a) Adding parser options if needed to support the attribute extension(s).
   b) Adding custom "take action" logic enabling the extension to process attribute extension options if needed.
   c) Displaying the attribute extension(s).

  In neutron alone, the following out-of-tree projects implement extensions falling under case #b:
  - vmware-nsx
  - gbpservice
  - quark
  - networking-cisco
  - networking-bigswitch
  - networking-h3c

  This support was provided in an ad-hoc fashion with the classic python
  clients (e.g. python-neutronclient) via it's ability to
  pass/handle/display arbitrary key/values. For example an API extension
  that adds a 'meta' boolean attribute to networks can be handled with
  the neutron client without any changes. The sample output snippets
  below show GET and POST (notice the 'meta' attribute that's added by
  the sample extension).

  -->
  stack@bvm2:~/devstack$ neutron --debug net-show my-meta-net
  ...
  RESP BODY: {"network":{"provider:physical_network":null,"ipv6_address_scope":null,"meta":true,
  ...
  +---------------------------+--------------------------------------+
  | Field                     | Value                                |
  +---------------------------+--------------------------------------+
  | admin_state_up            | True                                 |
  | availability_zone_hints   |                                      |
  | availability_zones        | nova                                 |
  | created_at                | 2017-07-21T17:31:23Z                 |
  | description               |                                      |
  | id                        | e824c797-1707-458c-9b71-8ee52f2c46c7 |
  | ipv4_address_scope        |                                      |
  | ipv6_address_scope        |                                      |
  | meta                      | True                                 |
  ...

  
  stack@bvm2:~/devstack$ neutron --debug net-create meta-net-2 --meta=false
  DEBUG: keystoneauth.session REQ: curl -g -i -X POST http://172.16.78.190:9696/v2.0/networks -H "User-Agent: python-neutronclient" -H "Content-Type: application/json" -H "Accept: application/json" -H "X-Auth-Token: {SHA1}4f63823e9b5041c7c2ac209a8068b2637ec717cf" -d '{"network": {"meta": "false", "name": "meta-net-2", "admin_state_up": true}}'
  <--

  Using the OSC, there's no way to achieve what was shown with the
  neutron client in the snippets above without updating python-
  openstacksdk's Network resource to add the attribute and then adding
  logic into neutron's network logic in the python-openstackclient.

  
  [1] https://github.com/openstack/neutron/blob/master/neutron/extensions/netmtu.py#L19
  [2] https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/extended_status.py
  [3] http://codesearch.openstack.org/?q=openstack.cli.extension&i=nope&files=setup.cfg&repos=

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1705755/+subscriptions