OpenStack/ML2 Mechanism Driver for UCSM Mitaka/Newton
How to obtain the mechanism driver?
networking-cisco repo is now simultaneously compatible with all Openstack releases starting from Mitaka. https://github.com/openstack/networking-cisco
New Features added in Mitaka/Newton
Support for Service Profile Templates
ucsm_host_list=<host name1>:<Service Profile or Service Profile Template>
In the previous releases, the UCSM mechanism driver user was asked only to use Service Profiles to configure their UCS Servers. If the servers were configured using Service Profile Templates, the user was asked to dissociate the Service Profile from its Template so that the plugin could modify it. The current version of the mechanism driver, can configure the Service Profile Templates directly and does not require the user to dissociate from the Service Profile Template. The user needs to be aware that modifying the Service Profile template would result in all Service Profiles derived from it to be modified.
Also, the Service Profile Templates do not have to be specified just at the root level, they can be specified with in a sub-directory. The same ucsm_host_list configuration can be configured using both formats. Here is a sample configuration that show the different formats that are allowed: ucsm_host_list=devstack-1:UCS-1-SPT, devstack-2:/org-root/Test/ls-UCS-2-SPT, devstack-3:UCS-3-SP
devstack1 is controlled by a Service Profile Template at the root level, devstack2 is a host controlled by a Service Profile Template defined in the subdirectory "Test" and lastly devstack-3 is a host controlled by a Service Profile defined at the root level.
Support for VNIC Templates
# VNIC Profile Template config per UCSM. vnic_template_list = <physnet name>:<VNIC template with path>:<comma separated list of UCS server ports>
VNIC Templates come in handy when a number of UCS server virtual ports need to be configured identically. These ports can all be attached to one VNIC Template and modifying this VNIC Template would cause the same configuration to be pushed to all the ports attached to this template. We are using this cool UCS Manager feature to make Openstack physnet configuration easier for the UCSM user. To take advantage of this feature, the cloud admin would have to provide the above configuration to the UCSM plugin.
The "vnic_template_list" is a comma separated list of individual config items specified in the format shown above. The UCS Server ports should correspond to Server ports that are physically connected to the physnet that is specified in the Neutron configuration.
Automatic Detection of Dynamically Added Compute Hosts
No new config required for the plugin.
It is really helpful for a cloud admin to dynamically add hosts to an existing Openstack cloud when there is a need for additional resources. To accommodate that, the UCSM plugin can now detect the Service Profile or Service Profile Template config for a compute host that is added to the Openstack cloud on the fly. The compute host that is being added dynamically needs to have the "Name" field associated with the Server(Equipment Tab on UCSM), to indicate the hostname as known to the hypervisor. No additional config needs to be provided to the UCSM plugin itself. If Nova compute decides to schedule a VM on this newly commissioned compute host, the UCSM plugin will learn this new compute hosts configuration for the 1st port that is requested on this compute host. This operation can take sometime depending on the number of UCS Servers in the cloud. After this discovery phase, the UCSM plugin would complete the learning on this compute host and all subsequent requests to this compute host would take a predictable amount of time.
Multi VLAN Trunk Support for SR-IOV ports
# SR-IOV Multi-VLAN trunk config section [sriov_multivlan_trunk] Neutron network name=<comma seperated list of VLAN-ids or VLAN-id ranges>
This feature is useful for SR-IOV ports that carry traffic on multiple VLANs. This feature allows the cloud admin to specify a list of VLANs that an SR-IOV port created on a particular Neutron network would have to carry. The UCSM plugin would take care of programming this list of VLAN-ids into the Port Profile that is associated with a SR-IOV port created on a Neutron network specified in the configuration. If this configuration is required for multiple networks, the cloud admin simply needs to add additional lines for each Neutron Network.