Welcome to Networking-Ansible Documentation¶

Prerequisites¶

To successfully install and configure the Networking-Ansible ML2 Driver, you will need a few prerequisites. Collecting this information and ensuring these resources are available will ensure a successful installation.

1. Switch credentials that allow configuration changes to the ports that the deployed baremetal guests are connected to.

   For security purposes it is important that you do not provide administrator access to the switch for networking-ansible. A user should be created and granted access for the permissions needed for networking-ansible.

   Networking-Ansible will need to configure a port in access mode and assign a VLAN to that port. It will optionally need access to create VLANs if you choose not to predefine the VLANs that will be used.

2. OpenStack must be installed with Neutron configured to provide VLAN tenant networking.

   This prerequisite is currently outside the scope of this document. Please refer to Neutron’s documentation or other guides to provide VLAN tenant networking.

Install¶

This section describes how to install and configure the Networking-Ansible Driver, code-named networking_ansible, on the controller node. This section assumes that you already have a working OpenStack environment with Neutron configured to provide VLAN tenant networking.

Configure¶

This section decribes how to configure Neutron configuration files to enable the networking-ansible ML2 driver and configure switch devices that will be managed by networking-ansible.

1. Configure type_drivers and mechanism_drivers and network_vlan_ranges.

   Add vlan to type_drivers, ansible to mechanism_drivers, and define the network_vlan_range that will be used by the openstack networks that use this driver.

   [ml2]
   type_drivers = vlan
   mechanism_drivers = ansible
   
   [ml2_type_vlan]
   network_vlan_ranges = physnet1:1000:1099
   

   • Do not remove other values from these comma delimited lists if there are are already values present. Append a comma and your value to the list.
   • physnet1 is an identifier configured in the bridge_mapping TODO(radez) doc ref to bridge_mapping
   • the VLAN range (1000:1099 in this example) is provided by the switch administor. This range is the VLAN IDs assigned by Neutron when a network is created.

2. Add a section for each switch device that will be managed by networking-ansible.

   Create a section for each host with a section name prefixed by ansible: in /etc/neutron/plugins/ml2/ml2_conf.ini.

   [ansible:myhostname]
   ansible_network_os=junos
   ansible_host=10.10.2.250
   ansible_user=ansible
   ansible_pass=password
   mac=01:23:45:67:89:AB
   

   • myhostname is an arbitrary internal identifier used only in ironic’s link_local_information.
   • ansible_network_os is a valid Ansible Networking value to indicate switch type. Tested with networking-ansible: openvswitch, junos Untested but valid with networking-ansible: eos, nxos See contributor/provider for more information.
   • ansible_host is the IP address or hostname used to connect to the switch.
   • ansible_user username of the credentials used to connect to the switch.
   • ansible_pass password of the credentials used to connect to the switch.
   • mac is the MAC address of the switch as provided by lldp. This is optional to provide and specific to OpenStack ML2 use cases. It is used for zero touch provisioning using Ironic introspection. Introspection gathers the switch’s MAC and node’s port provided by lldp and populates the baremetal node’s local_link_information. If this parameter is provided in the ML2 ini configuration it will be used to match against the lldp provided MAC to populate internally generated ansible playbooks with the appropriate host name for the switch.

   Additional available parameters:

   ansible_ssh_private_key_file=/path/to/ansible-ssh
   manage_vlans=True
   

   • ansible_ssh_private_key_file can be used as an alternative to ansible_pass to use ssh key authentication instead of password authentication.
   • manage_vlans is optional and defaults to True. Set this to False for a switch if networking-ansible should not create and delete VLANs on the device.

3. Restart the Neutron API service

   $ service neturon-server restart
   

Verify operation¶

Verify operation of the networking-ansible ML2 Driver service.

1. Grep the neutron logs for ansible and confirm the driver has been registered and configured. root access CLI commands:

   $ grep ansible /var/log/neutron/server.log
   INFO neutron.plugins.ml2.managers [-] Configured mechanism driver names: ['ansible']
   INFO neutron.plugins.ml2.managers [-] Loaded mechanism driver names: ['ansible']
   INFO neutron.plugins.ml2.managers [-] Registered mechanism drivers: ['ansible']
   

Next steps¶

Your OpenStack environment now includes the networking-ansible ML2 Driver.

To add additional services, see https://docs.openstack.org/.

Contributing¶

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

If you already have a good understanding of how the system works and your OpenStack accounts are set up, you can skip to the development workflow section of this documentation to learn how changes to OpenStack should be submitted for review via the Gerrit tool:

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

Pull requests submitted through GitHub will be ignored.

Bugs should be filed on Storyboard, not GitHub:

https://storyboard.openstack.org/#!/project/openstack/networking-ansible

Provider Support¶

Networking-Ansible contains provider switch specific functionality in an Ansible role that enables specific hardware devices per provider switch added to this role. The openstack-ml2 Ansible role is stored in networking-ansible’s etc/ansible/roles directory. A provider switch will be refered to as just a provider for the remainder of this document.