Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

Ce contenu n'est pas disponible dans la langue sélectionnée.

Chapter 9. Performing overcloud post-installation tasks

This chapter contains information about tasks to perform immediately after creating your overcloud. These tasks ensure your overcloud is ready to use.

9.1. Checking overcloud deployment status
Copier lien

To check the deployment status of the overcloud, use the openstack overcloud status command. This command returns the result of all deployment steps.

Procedure

  1. Source the stackrc file: 

    $ source ~/stackrc
    Copy to Clipboard Toggle word wrap

  2. Run the deployment status command: 

    $ openstack overcloud status
    Copy to Clipboard Toggle word wrap

    The output of this command displays the status of the overcloud: 

    +-----------+---------------------+---------------------+-------------------+
| Plan Name |       Created       |       Updated       | Deployment Status |
+-----------+---------------------+---------------------+-------------------+
| overcloud | 2018-05-03 21:24:50 | 2018-05-03 21:27:59 |   DEPLOY_SUCCESS  |
+-----------+---------------------+---------------------+-------------------+
    Copy to Clipboard Toggle word wrap

    If your overcloud uses a different name, use the --plan argument to select an overcloud with a different name: 

    $ openstack overcloud status --plan my-deployment
    Copy to Clipboard Toggle word wrap

9.2. Creating basic overcloud flavors
Copier lien

Validation steps in this guide assume that your installation contains flavors. If you have not already created at least one flavor, use the following commands to create a basic set of default flavors that have a range of storage and processing capabilities:

Procedure

  1. Source the overcloudrc file: 

    $ source ~/overcloudrc
    Copy to Clipboard Toggle word wrap

  2. Run the openstack flavor create command to create a flavor. The following options 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.

  3. The following example creates the default overcloud flavors: 

    $ 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
    Copy to Clipboard Toggle word wrap
Note

Use $ openstack flavor create --help to learn more about the openstack flavor create command.

9.3. Creating a default tenant network
Copier lien

The overcloud requires a default Tenant network so that virtual machines can communicate internally.

Procedure

  1. Source the overcloudrc file: 

    $ source ~/overcloudrc
    Copy to Clipboard Toggle word wrap

  2. Create the default Tenant network: 

    (overcloud) $ openstack network create default
    Copy to Clipboard Toggle word wrap

  3. create a subnet on the network: 

    (overcloud) $ openstack subnet create default --network default --gateway 172.20.1.1 --subnet-range 172.20.0.0/16
    Copy to Clipboard Toggle word wrap

  4. Confirm the created network: 

    (overcloud) $ openstack network list
+-----------------------+-------------+--------------------------------------+
| id                    | name        | subnets                              |
+-----------------------+-------------+--------------------------------------+
| 95fadaa1-5dda-4777... | default     | 7e060813-35c5-462c-a56a-1c6f8f4f332f |
+-----------------------+-------------+--------------------------------------+
    Copy to Clipboard Toggle word wrap

These commands create a basic Neutron network named default. The overcloud automatically assigns IP addresses from this network to virtual machines using an internal DHCP mechanism.

9.4. Creating a default floating IP network
Copier lien

This procedure contains information on how to create an external network on the overcloud. This network provides floating IP addresses to so that users can access virtual machines outside of the overcloud.

This procedure provides two examples:

  • Native VLAN (flat network)
  • Non-Native VLAN (VLAN network)

Use the example that best suits your environment.

Both of these example 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 9.7, “Validating the overcloud”.

By default, Openstack Networking (neutron) maps a physical network name called datacentre to the 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.

This procedure assumes a dedicated interface or native VLAN for the floating IP network.

Procedure

  1. Source the overcloudrc file: 

    $ source ~/overcloudrc
    Copy to Clipboard Toggle word wrap

  2. Create the public network:

    • Create a flat network for a native VLAN connection: 

      (overcloud) $ openstack network create public --external --provider-network-type flat --provider-physical-network datacentre
      Copy to Clipboard Toggle word wrap

    • Create a vlan network for non-native VLAN connections: 

      (overcloud) $ openstack network create public --external --provider-network-type vlan --provider-physical-network datacentre --provider-segment 201
      Copy to Clipboard Toggle word wrap

      The --provider-segment value defines the VLAN to use. In this case, it is 201.

  3. Create a subnet with an allocation pool for floating IP addresses. In this case, the IP range is 10.1.1.51 to 10.1.1.250: 

    (overcloud) $ 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
    Copy to Clipboard Toggle word wrap

    Make sure this range does not conflict with other IP addresses in your external network.

9.5. Creating a default provider network
Copier lien

A provider network in another type of external network connection that routes traffic from private tenant networks to external infrastructure network. The network is similar to a floating IP network but the provider network uses a logical router to connect private networks to the provide network.

This procedure provides two examples:

  • Native VLAN (flat network)
  • Non-Native VLAN (VLAN network)

Use the example that best suits your environment.

By default, Openstack Networking (neutron) maps a physical network name called datacentre to the 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

  1. Source the overcloudrc file: 

    $ source ~/overcloudrc
    Copy to Clipboard Toggle word wrap

  2. Create the provider network:

    • Create a flat network for a native VLAN connection: 

      (overcloud) $ openstack network create provider --external --provider-network-type flat --provider-physical-network datacentre --share
      Copy to Clipboard Toggle word wrap

    • Create a vlan network for non-native VLAN connections: 

      (overcloud) $ openstack network create provider --external --provider-network-type vlan --provider-physical-network datacentre --provider-segment 201 --share
      Copy to Clipboard Toggle word wrap

      The --provider-segment value defines the VLAN to use. In this case, it is 201.

    These example commands create a shared network. It is also possible to specify a tenant instead of specifying --share so that only the tenant has access to the new network.

    + If you mark a provider network as external, only the operator may create ports on that network.

  3. Add a subnet to the provider network to provide DHCP services: 

    (overcloud) $ 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
    Copy to Clipboard Toggle word wrap

  4. Create a router so that other networks can route traffic through the provider network: 

    (overcloud) $ openstack router create external
    Copy to Clipboard Toggle word wrap

  5. Set the external gateway for the router to the provider network: 

    (overcloud) $ openstack router set --external-gateway provider external
    Copy to Clipboard Toggle word wrap

  6. Attach other networks to this router. For example, run the following command to attach a subnet ‘subnet1’ to the router: 

    (overcloud) $ openstack router add subnet external subnet1
    Copy to Clipboard Toggle word wrap

    This command adds subnet1 to the routing table and allows traffic from virtual machines using subnet1 to route to the provider network.

9.6. Creating additional bridge mappings
Copier lien

Floating IP networks can use any bridge, not just br-ex, as long as you meet the following conditions:

  • NeutronExternalNetworkBridge is set to "''" in your network environment file.

  • You have mapped the additional bridge during deployment. For example, to map a new bridge called br-floating to the floating physical network, include the NeutronBridgeMappings parameter in an environment file: 

    parameter_defaults:
  NeutronBridgeMappings: "datacentre:br-ex,floating:br-floating"
    Copy to Clipboard Toggle word wrap

This method provides you with a way to create separate external networks after creating the overcloud. For example, to create a floating IP network that maps to the floating physical network, run these commands: 

$ source ~/overcloudrc
(overcloud) $ openstack network create public --external --provider-physical-network floating --provider-network-type vlan --provider-segment 105
(overcloud) $ 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
Copy to Clipboard Toggle word wrap

9.7. Validating the overcloud
Copier lien

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 instruction on using the OpenStack Integration Test Suite, see the OpenStack Integration Test Suite Guide.

The Integration Test Suite requires a few post-installation steps to ensure successful tests.

Procedure

  1. If running this test from the undercloud, ensure that the undercloud host has access to the overcloud’s Internal API network. 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: 

    $ source ~/stackrc
(undercloud) $ sudo ovs-vsctl add-port br-ctlplane vlan201 tag=201 -- set interface vlan201 type=internal
(undercloud) $ sudo ip l set dev vlan201 up; sudo ip addr add 172.16.0.201/24 dev vlan201
    Copy to Clipboard Toggle word wrap

  2. Before running the OpenStack Integration Test Suite, check that the heat_stack_owner role exists in your overcloud: 

    $ source ~/overcloudrc
(overcloud) $ openstack role list
+----------------------------------+------------------+
| ID                               | Name             |
+----------------------------------+------------------+
| 6226a517204846d1a26d15aae1af208f | swiftoperator    |
| 7c7eb03955e545dd86bbfeb73692738b | heat_stack_owner |
+----------------------------------+------------------+
    Copy to Clipboard Toggle word wrap

  3. If the role does not exist, create it: 

    (overcloud) $ openstack role create heat_stack_owner
    Copy to Clipboard Toggle word wrap
  4. Run the integration tests as described in the OpenStack Integration Test Suite Guide.

  5. After completing the validation, remove any temporary connections to the overcloud’s Internal API. In this example, use the following commands to remove the previously created VLAN on the undercloud: 

    $ source ~/stackrc
(undercloud) $ sudo ovs-vsctl del-port vlan201
    Copy to Clipboard Toggle word wrap

9.8. Protecting the overcloud from removal
Copier lien

Heat contains a set of default policies in code that you can override by creating /etc/heat/policy.json and adding customized rules. Add the following policy to deny everyone the permissions for deleting the overcloud. 

{"stacks:delete": "rule:deny_everybody"}
Copy to Clipboard Toggle word wrap

This prevents removal of the overcloud with the heat client. To allow removal of the overcloud, delete the custom policy and save /etc/heat/policy.json.

Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat