OpenStack installation with the Packstack installer

Living in the Clouds

Answer File

The Packstack installer uses the so-called Answer file (answers.txt), which includes all the parameters needed for OpenStack deployment. Although an Answer file is not required for an all-in-one installation, it is mandatory for a multinode deployment.

To generate a preliminary version of the Answer file, including the parameter default values, enter the command:

[root@controller ~]# packstack --gen-answer-file=/root/answers.txt

Some of the generated parameter default values will need to be modified to your needs, so you should edit the /root/answers.txt file and modify the parameters as in Listing 1 for the test installation. Table 1 has a brief description of the modified parameters.

Table 1

Modified answers.txt Parameters

Parameter	Action
`CONFIG_HEAT_INSTALL`	Install Heat Orchestration service with the OpenStack environment.
`CONFIG_NTP_SERVERS`	NTP servers needed by the message broker (RabbitMQ, Qpid) for internode communication.
`CONFIG_CONTROLLER_HOST`	Management IP address of the Controller node.
`CONFIG_COMPUTE_HOSTS`	Management IP addresses of the Compute nodes (comma-separated list).
`CONFIG_NETWORK_HOSTS`	Management IP address of the Network node.
`CONFIG_KEYSTONE_ADMIN_USERNAME`	Keystone admin username required for the OpenStack REST API and Horizon dashboard access.
`CONFIG_KEYSTONE_ADMIN_PW`	Keystone admin password required for the OpenStack REST API and Horizon dashboard access.
`CONFIG_NEUTRON_L3_EXT_BRIDGE`	OVS bridge name for external traffic; if you use a provider network for external traffic (assign floating IPs from the provider network), you can also enter the value `provider`.
`CONFIG_NEUTRON_ML2_TYPE_DRIVERS`	Network types to be used in this OpenStack installation.
`CONFIG_NEUTRON_ML2_TENANT_NETWORK_TYPES`	Default network type to be used for the tenant network creation.
`CONFIG_NEUTRON_ML2_VLAN_RANGES`	VLAN tagging range, along with the physical network (physnet), on which the VLAN networks will be created (physnet is required for flat and VLAN networks); if the physnet has no VLAN tagging assigned, networks created on this physnet will have flat type.
`CONFIG_NEUTRON_OVS_BRIDGE_MAPPINGS`	Physnet-to-bridge mapping (specifying to which OVS bridges the physnets will be attached).
`CONFIG_NEUTRON_OVS_BRIDGE_IFACES`	OVS bridge-to-interface mapping (specifying which interfaces will be connected as OVS ports to the particular OVS bridges).
`CONFIG_NEUTRON_OVS_BRIDGES_COMPUTE`	OVS bridge interface that will be connected to the integration bridge (`br-int`).
`CONFIG_PROVISION_DEMO`	Provision a demo project tenant.
`CONFIG_PROVISION_TEMPEST`	Create an OpenStack integration test suite.

Listing 1

answers.txt Modifications

CONFIG_HEAT_INSTALL=y
CONFIG_NTP_SERVERS=time1.google.com,time2.google.com
CONFIG_CONTROLLER_HOST=192.168.2.34
CONFIG_COMPUTE_HOSTS=192.168.2.35,192.168.2.36
CONFIG_NETWORK_HOSTS=192.168.2.34
CONFIG_KEYSTONE_ADMIN_USERNAME=admin
CONFIG_KEYSTONE_ADMIN_PW=password
CONFIG_NEUTRON_L3_EXT_BRIDGE=br-ex
CONFIG_NEUTRON_ML2_TYPE_DRIVERS=vlan,flat
CONFIG_NEUTRON_ML2_TENANT_NETWORK_TYPES=vlan
CONFIG_NEUTRON_ML2_VLAN_RANGES=physnet1:1100:1199,physnet0
CONFIG_NEUTRON_OVS_BRIDGE_MAPPINGS=physnet1:br-eth1,physnet0:br-ex
CONFIG_NEUTRON_OVS_BRIDGE_IFACES=br-eth1:eth1,br-ex:eth0
CONFIG_NEUTRON_OVS_BRIDGES_COMPUTE=br-eth1
CONFIG_PROVISION_DEMO=n
CONFIG_PROVISION_TEMPEST=n

OpenStack Deployment

Once the Answer file is ready, you can proceed with the deployment. To avoid time out errors during the deployment, in some cases, it's worth running the deployment command with an extended time out. The default --timeout value is 300 seconds, which I decided to extend to 600 seconds:

[root@controller ~]# packstack --answer-file=/root/answers.txt--timeout=600

The installation takes approximately 45 minutes, and it strictly depends on the hardware used. During this process, the installer prompts for the SSH password for each OpenStack node. After the successful deployment, you should see the final message shown in Listing 2.

Listing 2

Successful Deployment

**** Installation completed successfully ******
Additional information:
* File /root/keystonerc_admin has been created on OpenStack client host 192.168.2.34. To use the command line tools you need to source the file.
* To access the OpenStack Dashboard browse to http://192.168.2.34/dashboard .
Please, find your login credentials stored in the keystonerc_admin in your home directory.
* The installation log file is available at: /var/tmp/packstack/20180122-012409-uNDnRi/openstack-setup.log
* The generated manifests are available at: /var/tmp/packstack/20180122-012409-uNDnRi/manifests

If the critical parameters in the Answer file were prepared according to your requirements, a successful installation means that no further post-deployment configuration is needed on any node.

Post-Deployment Verification

Before you start working with your cloud, you should briefly verify its functionality and operation by opening a web browser and entering the Controller's IP address, as specified in the installation output of Listing 2 (i.e., http://192.168.2.34/dashboard ), to determine that the Horizon dashboard is accessible. If the dashboard is operational, you should see the Horizon login screen (Figure 2), where you can use the credentials set in the answers.txt file (i.e., admin /password ) to log in.

Figure 2: The login screen means the Controller is accessible.

Once logged in, navigate to: Admin | System | System Information and inspect all the tabs to make sure everything is working as expected. The Compute Services tab lists Nova-related daemons running on particular nodes in the cloud. All services should be in Status Enabled and State Up (Figure 3). The Network Agents tab lists all Neutron services working on different nodes (Figure 4).

Figure 3: The Compute Services tab shows all services are up and enabled.

Figure 4: The Network Agents tab lists which services are running on which nodes.

Next, check network configuration on the Controller node, which also runs Neutron network services. The management IP address is now assigned to the br-ex OVS bridge (as specified in the answers.txt file shown in Listing 1), and eth0 works as a back-end interface for this bridge (Listing 3). In fact, eth0 is a port connected to br-ex (Listing 4).

Listing 3

The Management IP and Back End

[root@controller ~]# ip addr show br-ex
10: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN qlen 1000
    link/ether d6:57:55:2f:b5:47 brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.34/24 brd 192.168.2.255 scope global br-ex
       valid_lft forever preferred_lft forever
    inet6 fe80::d457:55ff:fe2f:b547/64 scope link
       valid_lft forever preferred_lft forever
[root@controller ~]# ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master ovs-system state UP qlen 1000
    link/ether 52:54:00:6b:55:21 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::5054:ff:fe6b:5521/64 scope link
       valid_lft forever preferred_lft forever

Listing 4

Querying the Open vSwitch

[root@controller ~]# ovs-vsctl show
...
Bridge br-ex
        Controller "tcp:127.0.0.1:6633"
            is_connected: true
        fail_mode: secure
        Port phy-br-ex
            Interface phy-br-ex
                type: patch
                options: {peer=int-br-ex}
        Port "eth0"
            Interface "eth0"
        Port br-ex
            Interface br-ex
                type: internal
Bridge "br-eth1"
        Controller "tcp:127.0.0.1:6633"
            is_connected: true
        fail_mode: secure
        Port "eth1"
            Interface "eth1"
        Port "phy-br-eth1"
            Interface "phy-br-eth1"
                type: patch
                options: {peer="int-br-eth1"}
        Port "br-eth1"
            Interface "br-eth1"
                type: internal
    ovs_version: "2.7.3"

The br-eth1 OVS bridge was created to handle internal traffic, and the eth1 interface is connected as a port to br-eth1, acting as its back-end interface.

Packstack does not create external bridges (br-ex) on Compute nodes and does not modify their management IP settings, either, because they do not normally participate in external traffic outside the cloud infrastructure. Packstack only creates br-eth1 OVS bridges to handle internal traffic.

« Previous 1 2 3 Next »