openstack/neutron
Code Issues Proposed changes
Files
23f7da3021b14c07759ff639d3d86d6e09f8b16c
neutron/doc/source/devref/agent_extensions.rst
Nate Johnston 23f7da3021 Add L3 agent extension API object 
In L2 agent extensions, when the agent extension needed access to a
datastructure within the L2 agent, an agent extension API object was created.
This API object would be the interface permitting agent extensions to have
access to those objects internal to the L2 agent.

This change implements a similar agent extension API object for the L3 agent
extensions.  This is necessary to allow L3 agent extensions to have access to
the RouterInfo class, so that they can do lookups on it, for example
determining the namespace for a specific router.  Without this API object, the
L3 agent extension would not have access to this structure.

Co-Authored-By: Margaret Frances <margaret_frances@cable.comcast.com>

Partially-Implements: blueprint l3-agent-extensions

Change-Id: I85f89accbeefd820130335674fd56cb54f1449de
2016-08-31 11:15:51 -04:00

4.1 KiB
Raw Blame History

Agent extensions

All reference agents utilize a common extension mechanism that allows for the introduction and enabling of a core resource extension without needing to change agent code. This mechanism allows multiple agent extensions to be run by a single agent simultaneously. The mechanism may be especially interesting to third parties whose extensions lie outside the neutron tree.

Under this framework, an agent may expose its API to each of its extensions thereby allowing an extension to access resources internal to the agent. At layer 2, for instance, upon each port event the agent is then able to trigger a handle_port method in its extensions.

Interactions with the agent API object are in the following order:

  1. The agent initializes the agent API object.
  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, for instance, bridge wrappers with cookies allocated.
Agent API +--------------------------------------------------+
+-----+-----+ |
                                  +-----------+ |

| | +-----------+ | |

+---+-+-+---+ 2 +--------------+ 3 | | 4 | | Agent +-----+ Ext. manager +-----+--+ .... +--+-----+ +-----------+ +--------------+ | | | +-----------+ | +--+ Extension +--+ +-----------+

Each extension is referenced through a stevedore entry point defined within a specific namespace. For example, L2 extensions are referenced through the neutron.agent.l2.extensions namespace.

The relevant modules are:

  • neutron.agent.agent_extension: This module defines an abstract extension interface for all agent extensions across L2 and L3.
  • neutron.agent.l2.agent_extension:
  • neutron.agent.l3.agent_extension: These modules subclass neutron.agent.agent_extension.AgentExtension and define a layer-specific abstract extension interface.
  • neutron.agent.agent_extensions_manager: This module contains a manager that allows extensions to load themselves at runtime.
  • neutron.agent.l2.l2_extensions_manager:
  • neutron.agent.l3.l3_extensions_manager: Each of these modules passes core resource events to loaded extensions.

Agent API object

Every agent can pass an "agent API object" into its extensions in order to expose its internals to them in a controlled way. To accommodate different agents, each extension may define a consume_api() method that will receive this object.

This agent API object is part of neutron's public interface for third parties. All changes to the interface will be managed in a backwards-compatible way.

At this time, on the L2 side, only the L2 Open vSwitch agent provides an agent API object to extensions. See L2 agent extensions <l2_agent_extensions>. For L3, see L3 agent extensions <l3_agent_extensions>.

The relevant modules are:

  • neutron.agent.l2.agent_extension_api
  • neutron.agent.l3.agent_extension_api