Chapter 8. Performing overcloud post-installation tasks This chapter contains information about tasks to perform immediately after you create your overcloud. These tasks ensure your overcloud is ready to use. 8.1. Checking overcloud deployment status To check the deployment status of the overcloud, use the openstack overcloud status command. This command returns the result of all deployment steps. Procedure Source the stackrc file: Run the deployment status command: The output of this command displays the status of the overcloud: If your overcloud uses a different name, use the --stack argument to select an overcloud with a different name: Replace <overcloud_name> with the name of your overcloud. 8.2. Creating basic overcloud flavors Validation steps in this guide assume that your installation contains flavors. If you have not already created at least one flavor, complete the following steps to create a basic set of default flavors that have a range of storage and processing capabilities: Procedure Source the overcloudrc file: Run the openstack flavor create command to create a flavor. Use the following options to specify the hardware requirements for each flavor: --disk Defines the hard disk space for a virtual machine volume. --ram Defines the RAM required for a virtual machine. --vcpus Defines the quantity of virtual CPUs for a virtual machine. The following example creates the default overcloud flavors: Note Use USD openstack flavor create --help to learn more about the openstack flavor create command. 8.3. Creating a default tenant network The overcloud requires a default Tenant network so that virtual machines can communicate internally. Procedure Source the overcloudrc file: Create the default Tenant network: Create a subnet on the network: Confirm the created network: These commands create a basic Networking service (neutron) network named default . The overcloud automatically assigns IP addresses from this network to virtual machines using an internal DHCP mechanism. 8.4. Creating a default floating IP network To access your virtual machines from outside of the overcloud, you must configure an external network that provides floating IP addresses to your virtual machines. This procedure contains two examples. Use the example that best suits your environment: Native VLAN (flat network) Non-Native VLAN (VLAN network) Both of these examples involve creating a network with the name public . The overcloud requires this specific name for the default floating IP pool. This name is also important for the validation tests in Section 8.7, "Validating the overcloud" . By default, Openstack Networking (neutron) maps a physical network name called datacentre to the br-ex bridge on your host nodes. You connect the public overcloud network to the physical datacentre and this provides a gateway through the br-ex bridge. Prerequisites A dedicated interface or native VLAN for the floating IP network. Procedure Source the overcloudrc file: Create the public network: Create a flat network for a native VLAN connection: Create a vlan network for non-native VLAN connections: Use the --provider-segment option to define the VLAN that you want to use. In this example, the VLAN is 201 . Create a subnet with an allocation pool for floating IP addresses. In this example, the IP range is 10.1.1.51 to 10.1.1.250 : Ensure that this range does not conflict with other IP addresses in your external network. 8.5. Creating a default provider network A provider network is another type of external network connection that routes traffic from private tenant networks to external infrastructure network. The provider network is similar to a floating IP network but the provider network uses a logical router to connect private networks to the provider network. This procedure contains two examples. Use the example that best suits your environment: Native VLAN (flat network) Non-Native VLAN (VLAN network) By default, Openstack Networking (neutron) maps a physical network name called datacentre to the br-ex bridge on your host nodes. You connect the public overcloud network to the physical datacentre and this provides a gateway through the br-ex bridge. Procedure Source the overcloudrc file: Create the provider network: Create a flat network for a native VLAN connection: Create a vlan network for non-native VLAN connections: Use the --provider-segment option to define the VLAN that you want to use. In this example, the VLAN is 201 . Use the --share option to create a shared network. Alternatively, specify a tenant instead of specifying --share , so that only the tenant has access to the new network. Use the --external option to mark a provider network as external. Only the operator can create ports on an external network. Add a subnet to the provider network to provide DHCP services: Create a router so that other networks can route traffic through the provider network: Set the external gateway for the router to the provider network: Attach other networks to this router. For example, run the following command to attach a subnet subnet1 to the router: This command adds subnet1 to the routing table and allows traffic from virtual machines using subnet1 to route to the provider network. 8.6. Creating additional bridge mappings Floating IP networks can use any bridge, not just br-ex , provided that you map the additional bridge during deployment. Procedure To map a new bridge called br-floating to the floating physical network, include the NeutronBridgeMappings parameter in an environment file: With this method, you can create separate external networks after creating the overcloud. For example, to create a floating IP network that maps to the floating physical network, run the following commands: 8.7. Validating the overcloud The overcloud uses the OpenStack Integration Test Suite (tempest) tool set to conduct a series of integration tests. This section contains information about preparations for running the integration tests. For full instructions about how to use the OpenStack Integration Test Suite, see the Validating your cloud with the Red Hat OpenStack Platform Integration Test Suite . The Integration Test Suite requires a few post-installation steps to ensure successful tests. Procedure If you run this test from the undercloud, ensure that the undercloud host has access to the Internal API network on the overcloud. For example, add a temporary VLAN on the undercloud host to access the Internal API network (ID: 201) using the 172.16.0.201/24 address: Run the integration tests as described in the Validating your cloud with the Red Hat OpenStack Platform Integration Test Suite . After completing the validation, remove any temporary connections to the overcloud Internal API. In this example, use the following commands to remove the previously created VLAN on the undercloud: 8.8. Protecting the overcloud from removal You can set a custom policy for the Orchestration service (heat) to protect your overcloud from being deleted. To re-enable stack deletion, remove the prevent-stack-delete.yaml file from the custom_env_files parameter and run the openstack undercloud install command. Procedure Create an environment file named prevent-stack-delete.yaml . Set the HeatApiPolicies parameter: The heat-deny-action is a default policy that you must include in your undercloud installation. Set the heat-protect-overcloud policy to rule:deny_everybody to prevent anyone from deleting any stacks in the overcloud. Note Setting the overcloud protection to rule:deny_everybody means that you cannot perform any of the following functions: Delete the overcloud. Remove individual Compute or Storage nodes. Replace Controller nodes. Add the prevent-stack-delete.yaml environment file to the custom_env_files parameter in the undercloud.conf file: Run the undercloud installation command to refresh the configuration:

Commands:
source ~/stackrc
openstack overcloud status
+-----------+---------------------+---------------------+-------------------+ | Plan Name | Created | Updated | Deployment Status | +-----------+---------------------+---------------------+-------------------+ | overcloud | 2018-05-03 21:24:50 | 2018-05-03 21:27:59 | DEPLOY_SUCCESS | +-----------+---------------------+---------------------+-------------------+
openstack overcloud status --stack <overcloud_name>
source ~/overcloudrc
openstack flavor create m1.tiny --ram 512 --disk 0 --vcpus 1 openstack flavor create m1.smaller --ram 1024 --disk 0 --vcpus 1 openstack flavor create m1.small --ram 2048 --disk 10 --vcpus 1 openstack flavor create m1.medium --ram 3072 --disk 10 --vcpus 2 openstack flavor create m1.large --ram 8192 --disk 10 --vcpus 4 openstack flavor create m1.xlarge --ram 8192 --disk 10 --vcpus 8
source ~/overcloudrc
(overcloud) USD openstack network create default
(overcloud) USD openstack subnet create default --network default --gateway 172.20.1.1 --subnet-range 172.20.0.0/16
(overcloud) USD openstack network list +-----------------------+-------------+--------------------------------------+ | id | name | subnets | +-----------------------+-------------+--------------------------------------+ | 95fadaa1-5dda-4777... | default | 7e060813-35c5-462c-a56a-1c6f8f4f332f | +-----------------------+-------------+--------------------------------------+
source ~/overcloudrc
(overcloud) USD openstack network create public --external --provider-network-type flat --provider-physical-network datacentre
(overcloud) USD openstack network create public --external --provider-network-type vlan --provider-physical-network datacentre --provider-segment 201
(overcloud) USD openstack subnet create public --network public --dhcp --allocation-pool start=10.1.1.51,end=10.1.1.250 --gateway 10.1.1.1 --subnet-range 10.1.1.0/24
source ~/overcloudrc
(overcloud) USD openstack network create provider --external --provider-network-type flat --provider-physical-network datacentre --share
(overcloud) USD openstack network create provider --external --provider-network-type vlan --provider-physical-network datacentre --provider-segment 201 --share
(overcloud) USD openstack subnet create provider-subnet --network provider --dhcp --allocation-pool start=10.9.101.50,end=10.9.101.100 --gateway 10.9.101.254 --subnet-range 10.9.101.0/24
(overcloud) USD openstack router create external
(overcloud) USD openstack router set --external-gateway provider external
(overcloud) USD openstack router add subnet external subnet1
parameter_defaults: NeutronBridgeMappings: "datacentre:br-ex,floating:br-floating"
source ~/overcloudrc (overcloud) USD openstack network create public --external --provider-physical-network floating --provider-network-type vlan --provider-segment 105 (overcloud) USD openstack subnet create public --network public --dhcp --allocation-pool start=10.1.2.51,end=10.1.2.250 --gateway 10.1.2.1 --subnet-range 10.1.2.0/24
source ~/stackrc (undercloud) USD sudo ovs-vsctl add-port br-ctlplane vlan201 tag=201 -- set interface vlan201 type=internal (undercloud) USD sudo ip l set dev vlan201 up; sudo ip addr add 172.16.0.201/24 dev vlan201
source ~/stackrc (undercloud) USD sudo ovs-vsctl del-port vlan201
parameter_defaults: HeatApiPolicies: heat-deny-action: key: 'actions:action' value: 'rule:deny_everybody' heat-protect-overcloud: key: 'stacks:delete' value: 'rule:deny_everybody'
custom_env_files = prevent-stack-delete.yaml
openstack undercloud install