Chapter 8. Examples

The Cisco Nexus 1000V is a network switch designed for virtual machine access. It also provides advanced switching and security using VXLANs, ACLs, and IGMP snooping. The ml2 driver for the Cisco Nexus 1000V is contained in the networking-cisco repository, which you can install alongside the Neutron service.

The Overcloud image contains the Neutron Puppet module (puppet-neutron), which includes a class (neutron::plugins::ml2::cisco::nexus1000v) to configure Neutron to use the Cisco Nexus 1000V. This class is located in the manifests/plugins/ml2/cisco/nexus1000v.pp manifest from the module. The class uses a set of default parameters, which you can override, and then uses the neutron_plugin_ml2 library to configure the ml2 plugin to use the Cisco Nexus 1000V:

neutron_plugin_ml2 {
  'ml2/extension_drivers'                          : value => $extension_drivers;
  'ml2_cisco_n1kv/n1kv_vsm_ips'                    : value => $n1kv_vsm_ip;
  'ml2_cisco_n1kv/username'                        : value => $n1kv_vsm_username;
  'ml2_cisco_n1kv/password'                        : value => $n1kv_vsm_password;
  'ml2_cisco_n1kv/default_policy_profile'          : value => $default_policy_profile;
  'ml2_cisco_n1kv/default_vlan_network_profile'    : value => $default_vlan_network_profile;
  'ml2_cisco_n1kv/default_vxlan_network_profile'   : value => $default_vxlan_network_profile;
  'ml2_cisco_n1kv/poll_duration'                   : value => $poll_duration;
  'ml2_cisco_n1kv/http_pool_size'                  : value => $http_pool_size;
  'ml2_cisco_n1kv/http_timeout'                    : value => $http_timeout;
  'ml2_cisco_n1kv/sync_interval'                   : value => $sync_interval;
  'ml2_cisco_n1kv/max_vsm_retries'                 : value => $max_vsm_retries;
  'ml2_cisco_n1kv/restrict_policy_profiles'        : value => $restrict_policy_profiles;
  'ml2_cisco_n1kv/enable_vif_type_n1kv'            : value => $enable_vif_type_n1kv;
}

The director’s Heat template collection contains an environment file and registered templates to configure the Hiera data for the Cisco Nexus 1000V. The environment file is located in environments/cisco-n1kv-config.yaml and contains the following default content:

resource_registry:
  OS::TripleO::ControllerExtraConfigPre: ../puppet/extraconfig/pre_deploy/controller/cisco-n1kv.yaml
  OS::TripleO::ComputeExtraConfigPre: ../puppet/extraconfig/pre_deploy/controller/cisco-n1kv.yaml

parameter_defaults:
  N1000vVSMIP: '192.0.2.50'
  N1000vMgmtGatewayIP: '192.0.2.1'
  N1000vVSMDomainID: '100'
  N1000vVSMHostMgmtIntf: 'br-ex'

The resource_registry sets the preconfiguration resources for Controller and Compute nodes (OS::TripleO::ControllerExtraConfigPre and OS::TripleO::ComputeExtraConfigPre) to use puppet/extraconfig/pre_deploy/controller/cisco-n1kv.yaml as the template to use for preconfiguration. The parameter_defaults section includes some parameters to pass to these resources.

Including this environment file in the deployment defines the Hiera data, which the Puppet uses for the Neutron Puppet module’s parameters during configuration.

Starting the actual application of the Puppet configuration is automatic. The Heat template collection contains a set of core Puppet manifests for configuring the Controller and Compute nodes. These files contain logic that detects if the Cisco Nexus 1000V Hiera data is set. If so (by including cisco-n1kv.yaml in your deployment), the manifest includes the neutron::plugins::ml2::cisco::nexus1000v class as well as the Cisco Nexus 1000V’s VEM and VSM agents:

  if 'cisco_n1kv' in hiera('neutron_mechanism_drivers') {
    include neutron::plugins::ml2::cisco::nexus1000v

    class { 'neutron::agents::n1kv_vem':
      n1kv_source          => hiera('n1kv_vem_source', undef),
      n1kv_version         => hiera('n1kv_vem_version', undef),
    }

    class { 'n1k_vsm':
      n1kv_source       => hiera('n1kv_vsm_source', undef),
      n1kv_version      => hiera('n1kv_vsm_version', undef),
    }
  }

This means configuring the Overcloud to use Cisco Nexus 1000V only requires a few steps:

This defines the Cisco Nexus 1000V configuration as a part of the Overcloud’s Hiera data. Then the Overcloud uses this Hieradata to configure Neutron’s Nexus 1000V ml2 driver during the core configuration.

This example demonstrates how the director integrates network components from a certified vendor with the Overcloud’s Neutron service.

NetApp provides several solutions for integration with OpenStack storage components. This example shows the how NetApp Storage integrates with Cinder to provide a backend for block storage.

The drivers for Cinder are contained within the project itself, which is publically available on GitHub at https://github.com/openstack/cinder. The drivers for NetApp Storage are located in the cinder/volume/drivers/netapp/ directory of the repository. This means the drivers are automatically included with Red Hat OpenStack Platform.

The configuration for NetApp is contained in the Puppet module for cinder (puppet-cinder), which the Overcloud image also contains. The manifest in the Puppet modules that contains the configuration is located at manifests/backend/netapp.pp. This manifest uses the cinder_config library to add netapp settings to the Cinder configuration files:

cinder_config {
  "${name}/nfs_mount_options":            value => $nfs_mount_options;
  "${name}/volume_backend_name":          value => $volume_backend_name;
  "${name}/volume_driver":                value => 'cinder.volume.drivers.netapp.common.NetAppDriver';
  "${name}/netapp_login":                 value => $netapp_login;
  "${name}/netapp_password":              value => $netapp_password, secret => true;
  "${name}/netapp_server_hostname":       value => $netapp_server_hostname;
  "${name}/netapp_server_port":           value => $netapp_server_port;
  "${name}/netapp_size_multiplier":       value => $netapp_size_multiplier;
  "${name}/netapp_storage_family":        value => $netapp_storage_family;
  "${name}/netapp_storage_protocol":      value => $netapp_storage_protocol;
  "${name}/netapp_transport_type":        value => $netapp_transport_type;
  "${name}/netapp_vfiler":                value => $netapp_vfiler;
  "${name}/netapp_volume_list":           value => $netapp_volume_list;
  "${name}/netapp_vserver":               value => $netapp_vserver;
  "${name}/netapp_partner_backend_name":  value => $netapp_partner_backend_name;
  "${name}/expiry_thres_minutes":         value => $expiry_thres_minutes;
  "${name}/thres_avl_size_perc_start":    value => $thres_avl_size_perc_start;
  "${name}/thres_avl_size_perc_stop":     value => $thres_avl_size_perc_stop;
  "${name}/nfs_shares_config":            value => $nfs_shares_config;
  "${name}/netapp_copyoffload_tool_path": value => $netapp_copyoffload_tool_path;
  "${name}/netapp_controller_ips":        value => $netapp_controller_ips;
  "${name}/netapp_sa_password":           value => $netapp_sa_password, secret => true;
  "${name}/netapp_storage_pools":         value => $netapp_storage_pools;
  "${name}/netapp_eseries_host_type":     value => $netapp_eseries_host_type;
  "${name}/netapp_webservice_path":       value => $netapp_webservice_path;
}

The director’s Heat template collection contains an environment file and registered templates to configure the Hiera data for a NetApp Storage backend. The environment file is located in environments/cinder-netapp-config.yaml and contains the following default content:

resource_registry:
  OS::TripleO::ControllerExtraConfigPre: ../puppet/extraconfig/pre_deploy/controller/cinder-netapp.yaml

parameter_defaults:
  CinderEnableNetappBackend: true
  CinderNetappBackendName: 'tripleo_netapp'
  CinderNetappLogin: ''
  CinderNetappPassword: ''
  CinderNetappServerHostname: ''
  CinderNetappServerPort: '80'
  CinderNetappSizeMultiplier: '1.2'
  CinderNetappStorageFamily: 'ontap_cluster'
  CinderNetappStorageProtocol: 'nfs'
  CinderNetappTransportType: 'http'
  CinderNetappVfiler: ''
  CinderNetappVolumeList: ''
  CinderNetappVserver: ''
  CinderNetappPartnerBackendName: ''
  CinderNetappNfsShares: ''
  CinderNetappNfsSharesConfig: '/etc/cinder/shares.conf'
  CinderNetappNfsMountOptions: ''
  CinderNetappCopyOffloadToolPath: ''
  CinderNetappControllerIps: ''
  CinderNetappSaPassword: ''
  CinderNetappStoragePools: ''
  CinderNetappEseriesHostType: 'linux_dm_mp'
  CinderNetappWebservicePath: '/devmgr/v2'

The resource_registry sets the preconfiguration resources for Controller nodes (OS::TripleO::ControllerExtraConfigPre) to use puppet/extraconfig/pre_deploy/controller/cinder-netapp.yaml as the template to use for preconfiguration. The parameter_defaults section includes some parameters to pass to these resources.

Including this environment file in the deployment defines the Hiera data, which the Puppet uses for the Cinder Puppet module’s parameters during configuration.

Starting the actual application of the Puppet configuration depends on the CinderEnableNetappBackend parameter. The Heat template collection contains a set of core Puppet manifests for configuring Controller nodes. These files contain logic that detects if the cinder_enable_netapp_backend Hiera data is set. The Hiera data is set using the CinderEnableNetappBackend parameter in the preconfiguration. Including cinder-netapp-config.yaml in your deployment and leaving the CinderEnableNetappBackend: true as is means the Controller Puppet manifest includes the cinder::backend::netapp class and passes the Hiera data values from the environment file:

  if hiera('cinder_enable_netapp_backend', false) {
    $cinder_netapp_backend = hiera('cinder::backend::netapp::title')

    cinder_config {
      "${cinder_netapp_backend}/host": value => 'hostgroup';
    }

    if hiera('cinder::backend::netapp::nfs_shares', undef) {
      $cinder_netapp_nfs_shares = split(hiera('cinder::backend::netapp::nfs_shares', undef), ',')
    }

    cinder::backend::netapp { $cinder_netapp_backend :
      netapp_login                 => hiera('cinder::backend::netapp::netapp_login', undef),
      netapp_password              => hiera('cinder::backend::netapp::netapp_password', undef),
      netapp_server_hostname       => hiera('cinder::backend::netapp::netapp_server_hostname', undef),
      netapp_server_port           => hiera('cinder::backend::netapp::netapp_server_port', undef),
      netapp_size_multiplier       => hiera('cinder::backend::netapp::netapp_size_multiplier', undef),
      netapp_storage_family        => hiera('cinder::backend::netapp::netapp_storage_family', undef),
      netapp_storage_protocol      => hiera('cinder::backend::netapp::netapp_storage_protocol', undef),
      netapp_transport_type        => hiera('cinder::backend::netapp::netapp_transport_type', undef),
      netapp_vfiler                => hiera('cinder::backend::netapp::netapp_vfiler', undef),
      netapp_volume_list           => hiera('cinder::backend::netapp::netapp_volume_list', undef),
      netapp_vserver               => hiera('cinder::backend::netapp::netapp_vserver', undef),
      netapp_partner_backend_name  => hiera('cinder::backend::netapp::netapp_partner_backend_name', undef),
      nfs_shares                   => $cinder_netapp_nfs_shares,
      nfs_shares_config            => hiera('cinder::backend::netapp::nfs_shares_config', undef),
      netapp_copyoffload_tool_path => hiera('cinder::backend::netapp::netapp_copyoffload_tool_path', undef),
      netapp_controller_ips        => hiera('cinder::backend::netapp::netapp_controller_ips', undef),
      netapp_sa_password           => hiera('cinder::backend::netapp::netapp_sa_password', undef),
      netapp_storage_pools         => hiera('cinder::backend::netapp::netapp_storage_pools', undef),
      netapp_eseries_host_type     => hiera('cinder::backend::netapp::netapp_eseries_host_type', undef),
      netapp_webservice_path       => hiera('cinder::backend::netapp::netapp_webservice_path', undef),
    }
  }

This means configuring the Overcloud to use NetApp Storage only requires a few steps:

This defines the NetApp Storage configuration as a part of the Overcloud’s Hiera data. Then the Overcloud uses this Hieradata to configure Cinder’s NetApp backend during the core configuration.

This example demonstrates how the director integrates storage components from a certified vendor with the Overcloud’s Cinder service.