BP: Provider Validation for L3 Plugins

Blueprint spec on adding vendor validation capabilities
for L3 services for Juno.

Change-Id: Ic34376fe261e36d4341ff7b2f1727f4a897e7479

specs/juno/l3-svcs-vendor-validation.rst

@@ -0,0 +1,184 @@
+..
+ This work is licensed under a Creative Commons Attribution 3.0 Unported
+ License.
+
+ http://creativecommons.org/licenses/by/3.0/legalcode
+
+==========================================
+Provider Validation for L3 Plugins
+==========================================
+
+https://blueprints.launchpad.net/neutron/+spec/l3-svcs-vendor-validation
+
+Currently, validation of end user selections is tightly bound to the
+reference implementation. As a result, alternate providers cannot
+validate end user configuration selections, until after they have
+already been persisted.
+
+
+Problem description
+======================================
+
+When an L3 service request is received by Neutron, it invokes the
+corresponding service plugin, which *validates* and *persists* info
+for the request (typically in one step). Finally, the plugin will
+invoke the service driver to *apply* the changes.
+
+It is at the *apply* stage, when the provider's service driver has
+an opportunity to take action on the request. If the provider has
+additional constraints, it can reject the request, but the
+resource(s) will already have been persisted.
+
+For example, when creating a VPN IPsec site connection using an IKE
+policy that selected v2, the connection will pass validation, be
+persisted, and the service driver called. With the Cisco CSR,
+which currently does not support v2 via its REST API, the service
+driver can raise an exception during the *apply*. However, the
+connection will have already been created and persisted.
+
+In addition, if a service driver has persistence to perform, it
+must do that during the *apply* phase.
+
+
+Proposed change
+===============
+
+The proposal is to create three distinct phases for processing
+create and update requests, and allow the selected provider
+to participate in each of those phases, as needed.
+
+The request processing would be broken into validate, persist,
+and apply steps. The provider's service driver would have the
+option to take action during the validate and persist steps,
+ideally in any order desired (e.g. validate before or after
+the service plugin performs validation).
+
+Goal is to roll out the same proposal for all L3 service plugins.
+
+This will be a structural change, and not a behavorial change.
+
+
+Alternatives
+------------
+
+An alternative is to mark the resource status/state as *ERROR*, but
+the database will still be inconsistent with the actual state of
+the requested operation.
+
+
+Data model impact
+-----------------
+
+No changes to the database schema or operations is expected, other
+that it would now accurately reflect the actual state of the
+resources.
+
+
+REST API impact
+---------------
+
+No expected changes to REST APIs.
+
+
+Security impact
+---------------
+
+None.
+
+
+Notifications impact
+--------------------
+
+None?
+
+
+Other end user impact
+---------------------
+
+None.
+
+
+Performance Impact
+------------------
+
+Other that more indirection in calls between the plugin and service
+driver (in the same process), there is no other performance impact,
+and no significant performance impact expected.
+
+
+Other deployer impact
+---------------------
+
+None.
+
+
+Developer impact
+----------------
+
+Providers will want to update their service drivers to take advantage
+of the new ability to validate and reject requests, based on provider
+capabilities.
+
+
+Implementation
+==============
+
+Assignee(s)
+-----------
+
+
+Primary assignee:
+  pmichali
+
+Other contributors:
+  None
+
+Though anyone is welcome to help!
+
+
+Work Items
+----------
+
+For each L3 service create and update API:
+
+* Refactor plugin API implementations
+
+  * Split implementation into validate, persist, and apply steps
+  * Move plugin logic into corresponding steps
+
+* Modify service driver to permit access to sub-steps (hooks)
+* Update unit tests based on structural changes
+
+
+Dependencies
+============
+
+None
+
+
+Testing
+=======
+
+Since this is a structural change, it is expected that no additional
+tempest tests will be needed.
+
+Unit tests will need modification, mostly due to method name changes,
+but may also change due to better isolation of the logic. Tests that
+were checking both validation and persistence (or were doing
+persistence to check validation), can be split out into more isolated
+test cases. This should reduce the amount of overlap in test cases
+(possibly eliminating some tests), better isolation, and possibly
+better performance (not having to do several tasks to test some
+functionality).
+
+
+Documentation Impact
+====================
+
+None.
+
+
+References
+==========
+
+None at this time.