Agent specific API for L2 agent extensions
This proposal should be quick to implement and unblock extensions interested in injecting OpenFlow rules; while we work on a more long term solution that would manage feature flows in a more controlled way. Change-Id: I0c6937a747a7930f08a494cf237b6e50f141a49c Partial-Bug: #1517903
This commit is contained in:
parent
7d7c97247a
commit
9eb9d7d911
|
@ -0,0 +1,129 @@
|
|||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
======================================================
|
||||
Allow Open vSwitch agent extensions to own their flows
|
||||
======================================================
|
||||
|
||||
https://bugs.launchpad.net/neutron/+bug/1517903
|
||||
|
||||
In Liberty, `L2 agent extensions`_ and `L2 agent extension manager`_ were
|
||||
introduced. Those extensions are triggered on specific events (particularly, on
|
||||
port updates and deletes), but they have no way of interacting with the agent's
|
||||
underlying resources, e.g. bridges, flows, etc. Some features currently in
|
||||
development (SFC, QoS DSCP, others) require some level of coordination between
|
||||
an extension and the agent running it.
|
||||
|
||||
|
||||
Problem Description
|
||||
===================
|
||||
|
||||
One major use case where extensions need to coordinate with the agent that is
|
||||
running them arises from the Open vSwitch agent graceful restart feature added
|
||||
in Liberty cycle. For this feature, a per-session agent id is used to
|
||||
distinguish flows that belong to the current agent session from those that
|
||||
belong to the previous one. The problem starts when an extension wants to
|
||||
inject its own flows into the switch. Since those extensions don't have a way
|
||||
to determine what the current agent id is, they cannot mark their new flows
|
||||
with it, which results in the agent dropping all their flows on restart under
|
||||
the assumption that they are stale in the sense of "belonging" to the previous
|
||||
agent session.
|
||||
|
||||
Allowing each extension to reserve a unique cookie value known to the agent,
|
||||
and to use that value for its own flows, will be the first reference
|
||||
implementation agent-specific API that will be exposed through the new proposed
|
||||
mechanism. This will be achieved by exposing integration and tunnel bridges
|
||||
thru a light weight wrapper around Open vSwitch bridges that allocates and
|
||||
manages cookie values for extensions and hardens them from breaking flows that
|
||||
belong to other extensions.
|
||||
|
||||
Later, the agent-specific API will be extended once the extensions needs are
|
||||
better understood. One of the features planned for the future is a higher level
|
||||
flow management API that would abstract out the processing pipeline, allowing
|
||||
multiple flow-aware extensions to be managed in a more controlled manner
|
||||
(enforcing processing ordering, better safe guarding other features from
|
||||
accidental breakages by misbehaving extensions, etc.) Once that higher level
|
||||
API is implemented, we may consider deprecating the API proposed by this spec.
|
||||
|
||||
Note that additional APIs are out of scope for the proposal.
|
||||
|
||||
|
||||
Proposed Change
|
||||
===============
|
||||
|
||||
The proposed change will expand the extensions manager and the L2 agent
|
||||
extensions APIs with an optional agent-specific API object. The extension
|
||||
manager will in turn propagate the new API object to each of the extensions.
|
||||
An extension that needs to interact with the agent running it will be able to
|
||||
determine the agent type (e.g., Open vSwitch, Linuxbridge, SR-IOV, etc.) that
|
||||
is running it by inspecting the driver_type argument that is already passed
|
||||
into its initialize() method.
|
||||
|
||||
Since extensions can be maintained outside the Neutron tree, we should consider
|
||||
not breaking them with later agent API changes. Hence the agent API will be
|
||||
considered part of public Neutron API and will evolve with due attention to
|
||||
backwards compatibility concerns.
|
||||
|
||||
Since out-of-tree agents could already rely on extensions mechanism, the new
|
||||
API object argument will be optional in the extensions manager and in
|
||||
extensions themselves.
|
||||
|
||||
Only Open vSwitch will be updated to pass the agent API object of
|
||||
corresponding type into L2 agent extensions. Other agents will be extended with
|
||||
the mechanism as needs arise.
|
||||
|
||||
As part of the proposal, the Open vSwitch agent API object will include two new
|
||||
methods that will return wrapped and hardened bridge objects with cookie values
|
||||
allocated for calling extensions. Extensions will be able to use those wrapped
|
||||
bridge objects to set their own flows, while the agent will rely on the
|
||||
collection of those allocated values when cleaning up stale flows from the
|
||||
previous agent session::
|
||||
|
||||
+-----------+
|
||||
| Agent API +--------------------------------------------------+
|
||||
+-----+-----+ |
|
||||
| +-----------+ |
|
||||
|1 +--+ Extension +--+ |
|
||||
| | +-----------+ | |
|
||||
+---+-+-+---+ 2 +--------------+ 3 | | 4 |
|
||||
| Agent +-----+ Ext. manager +-----+--+ .... +--+-----+
|
||||
+-----------+ +--------------+ | |
|
||||
| +-----------+ |
|
||||
+--+ Extension +--+
|
||||
+-----------+
|
||||
|
||||
Interactions with the agent API object are in the following order::
|
||||
|
||||
#1 the agent initializes the agent API object (bridges, other internal state)
|
||||
#2 the agent passes the agent API object into the extension manager
|
||||
#3 the manager passes the agent API object into each extension
|
||||
#4 an extension calls the new agent API object method to receive bridge wrappers with cookies allocated.
|
||||
|
||||
Call #4 also registers allocated cookies with the agent bridge objects.
|
||||
|
||||
Note: the proposal does not cover major flow table rework suggested in the
|
||||
corresponding `openstack-dev@ mailing thread`_. Instead, a simpler approach is
|
||||
chosen for Mitaka, so that we unblock features interested in setting custom
|
||||
flows, and work on table management part of the mailing list proposal on our
|
||||
pace.
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
* Ihar Hrachyshka (ihrachys)
|
||||
* David Shaughnessy (davidsha)
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. target-notes::
|
||||
|
||||
* _`L2 agent extensions`: https://git.openstack.org/cgit/openstack/neutron/tree/neutron/agent/l2/agent_extension.py?id=b01e3084d135492850384f7732763ad40a1bbc0b
|
||||
* _`L2 agent extension manager`: https://git.openstack.org/cgit/openstack/neutron/tree/neutron/agent/l2/extensions/manager.py?id=b01e3084d135492850384f7732763ad40a1bbc0b
|
||||
* _`openstack-dev@ mailing thread` on agent-specific API for L2 agent extensions: http://lists.openstack.org/pipermail/openstack-dev/2015-December/081264.html
|
Loading…
Reference in New Issue