Merge "ML2 Mechanism Driver for Cisco DFA"
This commit is contained in:
Jenkins
Gerrit Code Review
commit
18f6621f44
247
specs/juno/cisco-dfa-mechanismdriver.rst
Normal file
247
specs/juno/cisco-dfa-mechanismdriver.rst
Normal file
@ -0,0 +1,247 @@
|
||||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
==========================================================
|
||||
Cisco Dynamic Fabric Automation (DFA) ML2 Mechanism Driver
|
||||
==========================================================
|
||||
|
||||
Launchpad blueprint:
|
||||
|
||||
https://blueprints.launchpad.net/neutron/+spec/ml2-mechnism-driver-for-cisco-dfa
|
||||
|
||||
The purpose of this blueprint it to build an ML2 Mechanism Driver for DFA.
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
Cisco Dynamic Fabric Automation (DFA) helps enable network automation and
|
||||
provisioning, to simplify both physical servers and virtual machine
|
||||
deployments and moves across the fabric. It uses network admin-defined
|
||||
profile templates for physical and VM projects.
|
||||
When a server admin provisions VMs and physical servers, instances of
|
||||
network policies are automatically created and applied to the network leaf
|
||||
switch. As VMs move across the fabric, the network policy is automatically
|
||||
applied to the leaf switch. More details of cisco DFA can be found in [1].
|
||||
|
||||
The following sections describe the proposed changes in neutron, a new
|
||||
ML2 mechanism driver, and make it possible to use openstack in such a
|
||||
topology.
|
||||
|
||||
This diagram depicts openstack deployment in Cisco DFA topology.
|
||||
|
||||
asciiflows::
|
||||
|
||||
XXXXXXXXXXXXX
|
||||
XXXXXXX XXXXXXXXX
|
||||
X +–––––––+ +––––––––+ X
|
||||
X |spine 1| ++ ++ |spine n | X
|
||||
+–––––––––+ X +–––––––+ +––––––––+ X
|
||||
|DCNM | X X
|
||||
|(Data | X X
|
||||
| Center | +––––––––+ X
|
||||
| Network +––––+ Leaf i | SWITCH FABRIC X
|
||||
| Manager)| +––––––––+ X
|
||||
+–––––+–––+ X X
|
||||
| X X
|
||||
| X+–––––––+ +–––––––+X
|
||||
+ | Leaf x|XXXX XX XXXX|Leaf z |
|
||||
| | +----+ | +---+
|
||||
REST API | | VDP| | |VDP|
|
||||
+ +––+–––++ +––++---+
|
||||
| +––––––––––––––+ | |
|
||||
| | Openstack | | |
|
||||
| | Controller | | |
|
||||
| | Node | +––––––+––––––––+ +––+––––––––––––+
|
||||
| | +–––––––––+ | | OVS | | OVS |
|
||||
| | |Cisco DFA| | +–––+-–-––––––––+ +–––+–-–––––––––+
|
||||
+–––––––+Mechanism| | | |LLDPad(VDP)| | |LLDPad(VDP)|
|
||||
| |Driver | | | +---––––––––+ ++ | +--–––––––––+
|
||||
| | | | | Openstack | | Openstack |
|
||||
+––+––––+––––+–+ | Compute node 1| | Compote node n|
|
||||
| +––––––––––+––––+ +––––––––––+––––+
|
||||
| | |
|
||||
+–––––––––––––––––––+––––––––––––––––––––+
|
||||
|
||||
As shown in the diagram above, each openstack compute node is connected
|
||||
to a leaf node and controller node is connected to a DCNM (Data Center
|
||||
Network Manager). The DCNM is responsible for provisioning, monitoring and
|
||||
troubleshooting of data center network infrastructures [2].
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
The requirements for ML2 Mechanism Driver to support cisco DFA are as follows:
|
||||
|
||||
1. DCNM exchanges information with openstack controller node using REST API.
|
||||
To support this, a new client should be created to handle the exchange.
|
||||
|
||||
2. When a project is created/deleted the same needs to be created/deleted on
|
||||
the DCNM.
|
||||
|
||||
3. New extension, dfa:cfg_profile_id, needs to be added to network resource.
|
||||
Configuration profile can be thought as extended network attributes of the
|
||||
switch fabric.
|
||||
|
||||
4. Periodic should be sent to DCNM to get all supported
|
||||
configuration profile and save it into a database.
|
||||
|
||||
5. The network information, such as subnet, segmentation ID, and configuration
|
||||
profile should be sent to DCNM, when network is created, deleted or updated.
|
||||
|
||||
6. Mechanism Driver needs to exchange information with OVS neutron agent when a
|
||||
VM is launched. Currently only plugin can have RPC call to ovs neutron agent.
|
||||
Mechanism driver need to setup RPC to exchange the information with ovs agent.
|
||||
|
||||
7. The DFA topology represent a network based overlay and it support more than
|
||||
4k segment. So new type driver is needed to handle this type of network and
|
||||
detailed is explained in [4].
|
||||
|
||||
8. Data path (OVS flow) should be programmed on compute nodes where instances
|
||||
are launched. The VLAN for the flow is obtained from an external process, that
|
||||
is LLDPad, running on computed node. More detail of process explained in [4].
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
None
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
||||
* Configuration profiles - keeps supported config profile by DCNM.
|
||||
* Configuration profile and network binding - keeps mapping between network
|
||||
and config profile.
|
||||
* Project - keeps mapping between project name and project ID.
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
||||
None
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
None
|
||||
|
||||
Notifications impact
|
||||
--------------------
|
||||
|
||||
None
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
|
||||
1. As it is mentioned before, when a network is created, list of configuration
|
||||
profile needs to be displayed. From horizon GUI or CLI, the information can
|
||||
be requested using list_config_profiles API, which will be added to the
|
||||
python-neutronclient.
|
||||
|
||||
2. Configuration parameters regarding DCNM (such as ip address,...) should be
|
||||
added to mechanism driver config file.
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
There are two options to query configuration profiles from DCNM, periodic and
|
||||
on demand.
|
||||
The on demand request may cause performance issue on create_network. As the
|
||||
reply to a request, has to be processed and it also include database access.
|
||||
On the other hand with periodic approach the information may not be available
|
||||
for duration of pooling time. Concerning performance, a periodic task can
|
||||
query and process the information.
|
||||
|
||||
There are create/update/delete_<resource>_post/precommit methods in the ML2
|
||||
mechanism driver. All the access to database for DFA mechanism driver is done
|
||||
in the precommit methods and postcommit methods are handling DCNM requests.
|
||||
|
||||
Other deployer impact
|
||||
---------------------
|
||||
|
||||
1. New configuration options for DCNM, that is ip address and credentials.
|
||||
2. Enabling notification in keystone.conf.
|
||||
3. Adding new config parameter to ml2_conf.init to define RPC parameters
|
||||
(i.e. topic's name) for neutron ovs agent and mechanism driver.
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
None
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
Nader Lahouti (nlahouti)
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
1. Change the setup.cfg to introduce 'cisco_dfa' as mechanism driver.
|
||||
|
||||
2. Events notifications should be enabled in keystone.conf.
|
||||
The mechanism driver relies on notification for project events (create/delete).
|
||||
The ‘cisco_dfa’ mechanism driver listens to these events and after processing
|
||||
them it sends request to the DCNM to create/delete project.
|
||||
'cisco_dfa' keep the projects info in a local database, as they will be used
|
||||
when sending delete request to DCNM.
|
||||
|
||||
3. Spawn a periodic task to send request to DCNM. The reply contains
|
||||
configuration profiles. The information will be saved in a database.
|
||||
If connection to DCNM fails invalidate the cached information.
|
||||
|
||||
4. Define new extension to network resource for configuration profile. The
|
||||
extensions will be added to supported aliases in the cisco_dfa mechanism
|
||||
driver class.
|
||||
|
||||
NOTE: ML2 plugin currently does not support extension in the mechanism driver.
|
||||
A new blueprint is opened to address this issue [5].
|
||||
|
||||
5. When an instance is created cisco_dfa needs to send information (such as
|
||||
instance’s name), to the external process (i.e. LLDPad) on the compute nodes.
|
||||
For that purpose RPC is needed to call an API on ovs_neutron_agent side.
|
||||
Then the API pass the information to LLDpad through a shared library
|
||||
(provided by LLDPad)
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
1. Changes in ovs_neutron_agent to program the flow [4].
|
||||
2. Need implementation of RPC for mechanism driver in ovs_neutron_agent.
|
||||
3. Support for extensions in ML2 mechanism drivers [5]
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
It is needed to have a setup as shown in the beginning of this page.
|
||||
It is not mandatory to have physical switches for that topology.
|
||||
The whole setup can be deployed using virtual switches (i.e. instead of
|
||||
having physical switch fabric, it can be replaced by virtual switches).
|
||||
For each module added to the mechanism driver, unit test is provided.
|
||||
Functional testing with tempest will be provided. The third-party Cisco DFA CI
|
||||
report will be provided to validate this ML2 mechanism driver.
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
Describe cisco DFA mechanism driver and configuration details.
|
||||
|
||||
References
|
||||
==========
|
||||
[1] http://www.cisco.com/go/dfa
|
||||
http://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/unified-fabric/white_paper_c11-728337.html
|
||||
http://www.cisco.com/c/en/us/solutions/data-center-virtualization/unified-fabric/dynamic_fabric_automation.html#~Overview
|
||||
|
||||
[2] http://www.cisco.com/c/en/us/products/cloud-systems-management/prime-data-center-network-manager/index.html
|
||||
|
||||
[3] https://blueprints.launchpad.net/horizon/+spec/horizon-cisco-dfa-support
|
||||
|
||||
[4] https://blueprints.launchpad.net/neutron/+spec/vdp-network-overlay
|
||||
|
||||
[5] https://blueprints.launchpad.net/neutron/+spec/neutron-ml2-mechanismdriver-extensions
|
||||
http://summit.openstack.org/cfp/details/240
|
||||
Loading…
Reference in New Issue
Block a user