Post Deploy Scripts The Post Deploy Scripts is a collection of ENEA specific software that can be used to easily modify existing environments. These scripts can be used in various situations, from installing new components to configuring existing ones in a fast and efficient way. They are located on the Fuel Master in /opt/enea/postdeployscripts/.
Post Deploy Provider Networks OpenStack Networking allows you to create and manage network objects such as networks, subnets, and ports, which other OpenStack services can use. Provider networks offer layer-2 connectivity to instances, with optional support for DHCP and metadata services. These networks connect or map, to existing layer-2 networks within the data center, typically using VLAN (802.1q) tagging to identify and separate them. Provider networks generally offer simplicity, performance, and reliability at the cost of flexibility. Provider networks only handle layer-2 connectivity for instances, lacking support for features such as routers and floating IP addresses. Please refer to the OpenStack documentation for examples on using provider networks. In the example provided here, an instance uses a provider (external) network that connects to the physical network infrastructure via layer-2 (bridging/switching). This network includes a DHCP server that provides IP addresses to instances.
Networking Option 1: Provider Networks Overview
DPDK acceleration is automatically enabled based on the setting of the Private Network in Fuel (See chapter 2.13, bullet 4 - Configure Compute nodes interfaces). If DPDK is enabled on one of the nodes, the playbook will configure the interface connected to the provider network as type DPDKOVSPort. Otherwise the interface will be configured as type OVSPort. You can check the port type by looking at the configuration files in /etc/network/interfaces.d on the corresponding node. For best results, it is recommended to run this playbook right after the deployment process has completed successfully. It can also be run at a later time, but in this case it is best to leave the neutron and OpenVSwitch configuration untouched. How to run the Provider Networks Playbook Log into the Fuel master. Install Ansible: yum install ansible Run the initialization script:cd /opt/enea/postdeployscripts/provider-net ./init.sh This will create a hosts file that will be used by Ansible to associate the nodes into groups and to access them. It will also create a file named samplenetworks.json, which will contain a single network in which all nodes (computes and controllers) are plugged in. The samplenetworks.json file will have the following content: { "networks": [ { "name": "prov-net", "nodes": [ { "interfaces": [], "name": "node-1" }, [...] # all other controller and compute nodes: node-X ] } } The interface list is empty and has to be populated by the user. If the interface lists are left empty the node will simply not be processed, though the script/playbook will attempt to perform certain checks. Populate the networks.json file (located in /opt/enea/postdeployscripts/provider-net/files/networks.json). The networks.json file will be used in the playbook to map the interfaces on the nodes to the corresponding provider networks to which they are connected. The samplenetworks.json file generated during step 3 can be used as a base for this file. Below is an example of the samplenetworks.json file as seen in step 3. with some interfaces included: { "networks":[ { "allocation-pool": { "end": "192.168.200.100", "start": "192.168.200.20" }, "enable-dhcp": "True", "gateway": "192.168.200.1", "name": "prov-net1", "network-type": "vlan", "nodes":[ { "interfaces": ["em5p144s0"], "name": "node-4" ] }, { "interfaces": ["em5p144s0"], "name": "node-5" } ], "provider-segment": "2251", "range": "192.168.200.0/24" } ] } cp samplenetworks.json /opt/enea/postdeployscripts/provider-net/files/networks.jsonThe snippet shown above infers the following: An OpenStack provider network called prov-net will be created. Two nodes (node-4 and node-5) each have an interface connected to the underlying physical network associated with the provider network. All of these components are lists in terms of json format, and can be extended accordingly, making it possible for there to be potentially X networks with Y nodes with Z interfaces. Final checklist: Verify that the node names in the file match the actual hostnames of the nodes. Check that the interfaces in the file exist on the nodes. Run the playbook:ansible-playbook deploy.yamlVarious checks are in place to minimize user error. deploy.yaml is located at /opt/enea/postdeployscripts/provider-net/deploy.yaml. After the playbook is executed the nodes will be rebooted. On the processed nodes there should be new OVS bridges, connecting the physical interfaces to br-int. For example, on a non-DPDK enabled setup, the new configuration will look like the following: Bridge br-prov-net Controller "tcp:127.0.0.1:6633" is_connected: true fail_mode: secure Port phy-br-prov-net Interface phy-br-prov-net type: patch options: {peer=int-br-prov-net} Port br-prov-net Interface br-prov-net type: internal ovs_version: "2.9.0"