Revision as of 19:04, 18 November 2013

Embrane Neutron Plugin

Scope

The current blueprint includes the implementation of an Embrane Neutron plugin which enables users to interface Neutron with the Embrane heleos platform.

Use Cases

Cloud service providers who choose to adopt OpenStack and Neutron for their cloud orchestration will also be able to use Embrane heleos via Neutron. Using the Embrane Neutron plugin, users can achieve any level of L2 isolation using existing plugins and build L3 connectivity through Embrane Distributed Virtual Appliances (DVAs) created by the Embrane Elastic Services Manager (ESM), the provisioning system used in the Embrane heleos platform. The ESM can rapidly provide per-tenant "core routers" within a pool of virtualized hosts. These routers are configurable through both Neutron itself or their own REST APIs.

Implementation

This section discusses the plugin implementation, with special focus to the plugin specific features and configurations. The plugin file list is shown below: neutron/plugins/embrane/EmbraneInit.py neutron/plugins/embrane/__init__.py neutron/plugins/embrane/agent/__init__.py neutron/plugins/embrane/agent/dispatcher.py neutron/plugins/embrane/agent/operations/__init__.py neutron/plugins/embrane/agent/operations/routerOperations.py neutron/plugins/embrane/l2base/__init__.py neutron/plugins/embrane/l2base/openvswitch/__init__.py neutron/plugins/embrane/l2base/openvswitch/openvswitch_support.py neutron/plugins/embrane/l2base/support_base.py neutron/plugins/embrane/l2base/support_exceptions.py neutron/plugins/embrane/plugin.py Additionally, more Embrane specific packages are included: neutron/plugins/embrane/api/* neutron/plugins/embrane/embranerest/*

Supported feature

The plugin supports the following features:

• Router;
• ExtraRoute;
• FloatingIp.

Using existing plugins for L2 connectivity

The main goal of the Embrane plugin is to interface OpenStack (specifically Neutron) with Embrane heleos providing L3-7 network services for cloud environments. For this reason, the Embrane heleos plugin leverages L2 connectivity to an existing plugin chosen at configuration time. The Embrane heleos plugin and the L2 plugin share information about the network implementation, which is used to implement L3. So any time a request is sent to Neutron, it will be directed to Embrane heleos where applicable. To achieve this, there are 2 main techniques that are used:

Plugin Inheritance

In 'neutron/plugins/embrane/plugins/*' where the actual plugins resides, each plugin class (i.e. EmbraneOvsPlugin) is created using the base Embrane plugin (neutron/plugins/embrane/plugin.py.EmbranePlugin) and the specific L2 plugin as bases. This will ensure, provided that everything is done correctly, that the L2 networks will be provided by an existing L2 plugin, while L3 connectivity will be managed by the Embrane heleos plugin. More details on how to create a specific Embrane plugin are provided below.

Plugin-in-Plugin

In order for this to work, the 2 plugins, Embrane heleos plugin and chosen L2 plugin, need to share some information about the actual network implementation. At the present state, only plugins which implement network isolation through VLANs can be used together with the Embrane heleos plugin. Support for different L2 isolation methods will be added in the future. The information sharing is implemented through a plugin inside the plugin, which means that for each L2 plugin that is supported, it's mandatory to create a new package inside 'neutron/plugins/embrane/l2base/' and a class that inherits from 'neutron/plugins/embrane/l2base/support_base.py'. This abstract class only defines one simple method, which shall be implemented by the support class in order to fulfill the contract.

Instructions to build a new Embrane plugin from a different base

See examples from: neutron.plugins.embrane.plugins.embrane_fake_plugin.EmbraneFakePlugin neutron.plugins.embrane.plugins.embrane_ovs_plugin.EmbraneOvsPlugin To build a new L2 support for the Embrane heleos Neutron plugin, one must first implement the specific l2base. Create a new package under: neutron.plugins.embrane.l2base And name it with the specific plugin technology. Create a python module and a class which extends support_base.SupportBase, implementing all its abstract methods. @abstractmethod def retrieve_utif_info(self, context, neutron_port=None, network=None): An example of support class can be found in 'neutron/plugins/embrane/l2base/openvswitch/openvswitch_support.py'. Once the contract is fulfilled (see examples and comments in the code for more info) create a new module under: neutron.plugins.embrane.plugins Referencing specific plugin technology (see existing examples) Inside the module define a class built as follows: class EmbraneNewPlugin(base.EmbranePlugin, l2.NewL2Plugin):

   _plugin_support = support.NewPluginSupport
   def __init__(self):
       First run plugin specific initialization, then Embrane's.
       self.supported_extension_aliases += ["extraroute", "router"]

#IF NEEDED

       l2.NewL2Plugin.__init__(self)
       self._run_embrane_config()

NOTE: The base order is very important. EmbranePlugin shall always be the first base of the built plugin, so the L3 requests can be correctly resolved (MRO)

NOTE: The plugin needs certain bases and extensions: • REQUIRED_EXTENSIONS = ["extraroute", "router"] • REQUIRED_BASES = (ExtraRoute_db_mixin,) Add them if needed (i.e. the L2 plugin doesn't natively support them).

Asynchronous Calls

To avoid excessive wait time on long operations, the calls to the Embrane heleos plugin are executed asynchronously and by a different thread per router. This means that each request will be sent to the dispatcher ('neutron/plugins/embrane/agent/dispatcher.py') which will serve each router using a different thread. All operations will be queued and executed sequentially, while the available database information on the specific resource will be returned to the user (Nova style). Moreover, the router state attribute is used to tell the user when a router is busy with an operation:

Table 1. Status Values

So when the model is changed (via POST, PUT or DELETE for example) the call may return before the actual operation is executed on the virtual system, putting the router in a 'PENDING_*' state. Subsequent GETs shall always reflect the current status of the virtual appliance itself. When a router is in a given state, only a subset of operations can be executed on it.

Configuration

The configuration file is stored in 'etc/neutron/plugins/embrane/heleos_conf.ini', this section explains the meaning of each field (example are provided in the configuration class itself).

• esm_mgmt: management address of the ESM, the Embrane heleos module that is installed separately and which will actually provision the routers inside the cloud environment;
• admin_username: admin username for authenticating against the ESM api;
• admin_password: admin password for authenticating against the ESM api;
• router_image: ID of the router image stored inside the ESM, which will be used to create the routers;
• *_id: a series of product specific resources that can be specified inside the plugin, or alternatively, from the product itself.

etc/neutron/neutron.conf example:

• core_plugin = neutron.plugins.embrane.plugins.embrane_ovs_plugin.EmbraneOvsPlugin