Jump to: navigation, search

Difference between revisions of "Neutron/EmbraneNeutronPlugin"

(Created page with "= Embrane Neutron Plugin = ==Scope== The present blueprint aims at the implementation of a Neutron plugins which allows users to interface Neutron with Embrane's heleos ...")
 
m (Network Overview)
Line 12: Line 12:
 
   
 
   
 
== Network Overview==
 
== Network Overview==
 
+
[TBD]
In order to work, the Embrane's Plugin requires Embrane's heleos platform to be in place.
 
The platform controller, called ESM, will use a pool of compute resources (which can be dedicated, or shared with the OpenStack environment) to provision virtual network services (in this specific case, routers).
 
 
 
This means that, for example, every time a tenant requests a Router creation to the plugin, the latter will ask to the ESM to spawn a virtual network service inside the specific hardware pool, and to configure it as a Router.
 
Then the tenant may ask to attach a Router interface to an existing network; In this case the plugin will gather all the information needed about the specified L2 netwotk, and communicate them to the ESM which will make the structural and configuration changes on the Router accordingly (e.g. If a gateway interface is set in the router, the plugin will both ask to the ESM to place a new interface, and to the Router itself to configure the default gateway inside the specified subnet).
 
  
 
== Implementation==
 
== Implementation==

Revision as of 21:35, 2 August 2013

Embrane Neutron Plugin

Scope

The present blueprint aims at the implementation of a Neutron plugins which allows users to interface Neutron with Embrane's 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's heleos platform with the API and workflows set they are comfortable with.

Using the Embrane's plugin, the users can achieve any level of L2 isolation using the existing plugins (when supported), while leveraging L3 connectivity through Embrane's provisioning system, which can rapidly provide per tenant "core routers" in a pool of dedicated/shared physical hosts. These routers are configurable through both Neutron itself or their own REST APIs.

Network Overview

[TBD]

Implementation

This session discusses the plugin implementation, with special focus to the plugin specific features and configurations.

The plugin file list is the following:

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, three more packages are defined:

neutron/plugins/embrane/api/*
neutron/plugins/embrane/common/*	
neutron/plugins/embrane/embranerest/*	

The files inside these packages are backend-specific, and represent the set of tools used to interact with the Embrane's platform. They are a dependency for the plugin and may be distributed separately at first.

Supported feature

The plugin supports the following features:


Using existing plugins for L2 connectivity

The Embrane Neutron Plugin main goal is of course to interface OpenStack (specifically Neutron) with heleos, which provides L3-7 network services for cloud environments. For this reason, the Embrane Plugin lends the leveraging of L2 connectivity to an existing Plugin chosen at configuration time. The Embrane Plugin and the L2 plugin share information about the network implementation, which will be used to implement L3. So any time a request is sent to Neutron, it will be directed to the Embrane Plugin if is part of the API set showed in the previous section, to the L2 plugin otherwise.

To achieve this, there are 2 main techniques that have been used:

Plugin Inheritance

In 'neutron/plugins/embrane/plugin.py' (plugin main module) the main class 'EmbranePlugin' is created at runtime starting from class '__EmbranePlugin'. This is done looking at the configuration file, assuring that the specified L2 plugin is a valid one, and creating a new class which attribute and methods (in general, the full dict) coincides with '__EmbranePlugin', but also inherits from the configured L2 plugin, from which 'EmbranePlugin' will get all the implemented methods overriding everything related with L3 connectivity. Also, all the necessary inheritances are set unless already present on the base L2 plugin.

Plugin-in-Plugin

In order to get all this to work, the 2 plugins (Embrane's and L2) need to share some information about the actual network implementation. At the present state, only plugins which implements network isolation through VLANs can be used together with Embrane's plugin. Support for different L2 isolation will be added in the future. This "information sharing" is implemented through a "Plugin inside the Plugin", which means that for each L2 plugin that is to be 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.

@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'.

Asynchronous Calls

To avoid too much wait time on long operations, the calls to the Embrane Plugin will be 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, in which all the 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, Router state attribute is used to tell the user when a Router is busy with an operation:

Table 1. Status Values

Name
ACTIVE
PENDING_CREATE
PENDING_UPDATE
PENDING_DELETE
INACTIVE
ERROR


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).

  • l2_plugin: path to one of the existing L2 plugins which will work together with the Embrane's plugin;
  • l2_support: path to one of the existing L2 support class (see the section above);
  • esm_mgmt: management address of the ESM, the Embrane module that is installed separately and which will actually provision the routers inside the cloud environent;
  • admin_username: admin username for authenticating against the ESM;
  • admin_password: admin password for authenticating against the ESM;
  • router_image: ID to the router image stored inside the ESM, which will be used to create the routers;
  • *_id: a series of resources product specific that can be specified inside the plugin, or alternatively, from the product itself.