networking-oneview 0.0.2

Overview

The mechanism driver interacts with Neutron and OneView to dynamically reflect networking operations made by OpenStack on OneView. With these operations it’s possible to a OneView administrator to know what is happening in OpenStack System which is running in the Data Center and also automatizes some operations previously required to be manual.

The diagram below provides an overview of how Neutron and OneView will interact using the OneView Mechanism Driver. OneView Mechanism Driver uses HPE Oneview SDK for Python to provide communication between Neutron and OneView through OneView’s REST API.

Flows:

+---------------------------------+
|                                 |
|       Neutron Server            |
|      (with ML2 plugin)          |
|                                 |
|           +---------------------+
|           |       OneView       |  Ironic API  +----------------+
|           |      Mechanism      +--------------+     Ironic     |
|           |       Driver        |              +----------------+
+-----------+----------+----------+
                       |
             REST API  |
                       |
             +---------+---------+
             |     OneView       |
             +-------------------+

The OneView Mechanism Driver aims at having the Ironic-Neutron integration for multi-tenancy working with nodes driven by the OneView drivers for Ironic.

How the driver works

The OneView Mechanism Driver considers that not all networking operations that are performed in OpenStack need to be reflected in OneView. To identify if a certain request should be executed by the driver it might check if the networks and ports are related with networks/connections which should be reflected OneView.

For Network Operations, the driver checks if the physical provider-network From Neutron network belongs to is defined as one of the “managed networks” of the driver. The concept of “managed networks” refers to the networks configured in the driver config file with a mapping to attached it to an Uplink Set in OneView. Operations of Networks with no mappings are just ignored by the driver.

These mappings configuration can be made in the configuration file using the “uplinkset_mappings” and “flat_net_mappings” attributes, as follows:

• “uplinkset_mappings” are used to define which provider networks from Neutron should be controlled by the OneView Mechanism Driver. In “uplinkset_mappings” attribute it’s necessary to define pairs of Provider Network: Uplink Set UUID to represent desired mappings of Neutron networks to the Uplink Sets the networks that will be created in OneView to reflect them might be attached to have external access. These mappings can be related with “Ethernet” Uplink Sets to support VLAN networks or “Untagged” Uplink Sets to support flat network. In the case of mappings using “Ethernet” Uplink Sets, OneView not allows that more than one network use the same VLAN ID in the same Uplink set and only one mapping is allowed per Logical Interconnect. In the case of “Untagged” Uplink Sets OneView restricts that only one network can be configured to use it.

• “flat_net_mappings” are used to define manual mappings of specific flat provider networks from Neutron to existing Untagged networks in OneView. This configuration can be done to allow OneView administrator to use a configured environment instead of create an entire new one interacting with OpenStack. When a network is mapped with “flat_net_mappings” no operations in OneView are performed since it is considered that all environment was correctly configured by OneView Administrator.

In the case of Port Operations, only ports related to managed networks and with the “local_link_information” field populated are considered. When the driver identifies that “local_link_information” exists in a given port, it checks if it contains a Server Hardware UUID and boot information. The mech driver also uses the information of the MAC address of the requested port to identify the specific NIC of the Server Profile where the operation should be executed. This information can be directly configured in the Neutron port or passed by Ironic port field “local_link_connection”.

Considering these restrictions, OneView Mechanism Driver is capable of:

• Create a network in OneView for each network in Neutron to physical provider-networks configured in the driver config file

• Add networks to Uplink Sets in OneView according to Uplink Set mappings defined to the physical provider-network in the driver config file

  • “Ethernet” Uplink Sets are used with “vlan” typed provider networks

  • “Untagged” Uplink Sets are used with “flat” typed provider networks

  • Other kinds of Uplink Sets neither other types of provider networks are used

• Manual mapping of Neutron flat networks onto specified pre-existing networks of OneView

  • This covers migration from the flat model to the multi-tenant model

• Create, remove and update connections in Server Profiles, implementing Neutron port binding

  • Works only with vif_type = baremetal

  • Expects Server Hardware UUID and boot priority in the local_link_information of the port

OneView Mechanism Driver also implements a fault tolerance process to guarantee that all networks and ports that are present in Neutron are correctly reflected in OneView.

Ironic Configuration

By default, Ironic is configured to use flat networks during deployment process. To use Ironic-Neutron integration to provide networks isolation during deployment, some configurations are necessary. In ironic.conf file the following configuration should be done:

enabled_network_interfaces = flat,noop,neutron
default_network_interface = neutron
cleaning_network_uuid = neutron_cleaning_network_UUID
provisioning_network_uuid = neutron_provisioning_network_UUID

As mentioned in the previous section, the OneView Mechanism Driver needs to receive the “local_link_connection” from Ironic ports to perform networking ports operations. Once Ironic ports don’t have any information stored by default, it’s necessary to update existing ports with the desired data to data field as follow:

ironic --ironic-api-version 1.22 port-update Ironic_node_ID replace local_link_connection="{\"switch_id\": \"aa:bb:cc:dd:ee:ff\", \"port_id\": \"\", \"switch_info\": \"{'server_hardware_uuid': 'value', 'bootable':'true/false'}\"}"

In “local_link_connection”, switch_id and port_id are necessary to identify specific the switch/port where the operation should be performed, but as OneView Mechanism Driver doesn’t deals directly with switches, this information is not necessary. “switch_info” attribute can receive any information and because of it, will be to configured with information demanded by OneView Mechanism Driver. Two information need to be passed: ‘server_hardware_uuid’ and ‘bootable’. ‘server_hardware_uuid’ identifies in which Server Hardware the connection to represent the new port will be created and ‘bootable’ indicates if this connection will be bootable or not. To identify the port where the connection need to be created, the MAC address already configured in the Ironic port will be used.

Install

1. The ML2 Mechanism Driver:

$ pip install networking-oneview

2. Making ML2_conf.ini file configurations:

• Edit the /etc/neutron/plugins/ml2/ml2_conf.ini file. Find the correspondent line and insert the word oneview as follow:

mechanism_drivers = openvswitch,linuxbridge,genericswitch,oneview

• Find the correspondent line and insert the flat physical networks:

[ml2_type_flat]

flat_networks = public,<flat-physical-network1-name>,<flat-physical-network2-name>*

• Find the correspondent line and insert the vlan physical networks:

[ml2_type_vlan]

network_vlan_ranges = public,<vlan-physical-network1-name>,<vlan-physical-network2-name>

• Copy the following lines to the end of this file:

[oneview]

oneview_ip=<OneView server IP address>

username=<OneView username>

password=<OneView password>

uplinkset_mapping=<physical-network1-name>:<oneview-uplinkset1_uuid>,<physical-network2-name>:<uplinkset2_uuid>,...

flat_net_mappings=<flat-physical-network1-name>:<oneview-network1-id>,<flat-physical-network2-name>:<oneview-network2-id>,...

ov_refresh_interval=<ov_refresh_interval>

tls_cacert_file = <TLS File Path>

“ov_refresh_interval” is used to configure the period (in seconds) in which the mechanism driver will execute the periodic synchronization to check if any inconsistence exists between Neutron and OneView and correct them if possible. This attribute is optional and if not configured the default value is 3600 seconds.

To set TLS options for the communication with OneView, it is necessary to download the credentials(appliance.com.crt) from OneView.

• Examples of the lines are:

oneview_domain_name=OneView_Server_Name

username=admin

password=password

uplinkset_mapping=physnet1:8b4d1932-2528-4f32-8b00-3879cfa1de28,physnet2:f0be6758-4b4b-4596-8aa1-6c38d2422d4f

flat_net_mappings=physnet3:4e45ab21-ba2e-490a-81f9-2226c240f3d9,physnet4:66666666-ba2e-490a-81f9-2226c240f3d9

ov_refresh_interval=3600

tls_cacert_file = /home/ubuntu/certificate/appliance.com.crt


[ml2_type_flat]

flat_networks = public,physnet3,physnet4

[ml2_type_vlan]

network_vlan_ranges = public,physnet1,physnet2

4. Making setup.cfg file configurations:

• Edit the /opt/stack/neutron/setup.cfg file. Under:

neutron.ml2.mechanism_drivers =

in this file, insert the following:

oneview = networking_oneview.ml2.drivers.oneview.mech_oneview:OneViewDriver

5. Restart Neutron:

• Restart the neutron service. If everything is well, the mechanism driver is working.

6. Creating the database tables:

• Run the migration script to create the database tables necessary for the mechanism driver function.

• Go to the mechanism driver download folder in the following path:

$ cd <download_directory>/networking-oneview/networking_oneview/db

• Then run:

$ sudo python oneview_network_db.py install

• If any error related to db log occurs, execute:

$ cd /opt/stack/neutron/

$ neutron-db-manage upgrade head

License

OneView ML2 Mechanism Driver is distributed under the terms of the Apache License, Version 2.0. The full terms and conditions of this license are detailed in the LICENSE file.

Contributing

You know the drill. Fork it, branch it, change it, commit it, and pull-request it. We are passionate about improving this project, and glad to accept help to make it better. However, keep the following in mind:

• Contributed code must have the same license of the repository.

• We reserve the right to reject changes that we feel do not fit the scope of this project, so for feature additions, please open an issue to discuss your ideas before doing the work.

• If you would like to contribute to the development of OpenStack, you must follow the steps in this page:

  http://docs.openstack.org/infra/manual/developers.html

• Once those steps have been completed, changes to OpenStack should be submitted for review via the Gerrit tool, following the workflow documented at:

  http://docs.openstack.org/infra/manual/developers.html#development-workflow