3.2. Running Packstack Interactively

⁠3.2. Running Packstack Interactively

The procedure below lists all the questions that Packstack prompts you to answer when run in interactive mode. Based on your choices, some of the options might be skipped.

Important

If a step is self-explanatory, only the step is included.
All IP addresses included in the following procedure are examples; you must replace these addresses with those in your own network.
You do not have to log in as root to run packstack. However, you must provide root credentials for each machine on which you deploy services.
If not specified during the procedure, passwords are randomly generated and available in the answer file after installation.

⁠

Procedure 3.2. Deploy OpenStack Interactively

Install the Packstack utility
```
# yum install openstack-packstack
```
Start the installation
```
# packstack
```
If you want more output from Packstack, append the --debug parameter.
```
Enter the path to your ssh public key to install on servers:
```
This value is used for each server in the OpenStack deployment. If you already have a public key, enter its path; otherwise, press Enter and the tool will generate one for you and save it to ~/.ssh/id_rsa.pub.
```
Should Packstack install MariaDB [y|n]  [y] :
```
Packstack can create a single database node, or you can use a pre-existing database (a MariaDB cluster can also be specified). If you select n, Packstack asks you for credentials and uses CONFIG_MARIADB_HOST as the database address.

Should Packstack install OpenStack Image Service (Glance) [y|n]  [y] :  
Should Packstack install OpenStack Block Storage (Cinder) [y|n]  [y] :  
Should Packstack install OpenStack Compute (Nova) [y|n]  [y] :  
Should Packstack install OpenStack Networking (Neutron) [y|n]  [y] :  
Should Packstack install OpenStack Dashboard (Horizon) [y|n] [y] :  
Should Packstack install OpenStack Object Storage (Swift) [y|n]  [y] :
Should Packstack install OpenStack Metering (Ceilometer) [y|n]  [y] :  
Should Packstack install OpenStack Orchestration (Heat) [y|n]  [n] :  
Should Packstack install OpenStack Clustering (Sahara) [y|n]  [n] :  
Should Packstack install OpenStack Database (Trove) [y|n]  [n] :  
Should Packstack install OpenStack Bare Metal (Ironic) [y|n]  [n] :

Important

If OpenStack Networking is declined, Compute networking is installed.

```
Should Packstack install OpenStack client tools [y|n] [y] :
```
Red Hat recommends that the client tools be installed for a PoC deployment (default).
```
Enter list of NTP server(s). Leave plain if Packstack should not install ntpd on instances:
```
Optionally, all servers in the deployment can retrieve date and time information using Network Time Protocol (NTP). The NTP server value is only important for multi-node deployments.
⁠
Example 3.3. Using the default Red Hat Enterprise Linux NTP servers
```
Enter list of NTP server(s). Leave plain if Packstack should not install ntpd on instances.: 0.rhel.pool.ntp.org, 1.rhel.pool.ntp.org
```
```
Should Packstack install Nagios to monitor openstack hosts [y|n]  [y] :
```
OpenStack can use Nagios to provide advanced monitoring facilities for the OpenStack environment.
```
Enter a comma separated list of server(s) to be excluded. Leave plain if you don't need to exclude any server:
```
If you have previously configured servers that you do not want Packstack to overwrite, you can specify their IP addresses to be excluded.
```
Do you want to run OpenStack services in debug mode [y|n] [n]:
```
The debug setting can later be updated in each service's configuration file.
Specify deployment addresses. The default deployment address is that of the host on which Packstack is being run.
1. ```
Enter the IP address of the controller host  [192.0.43.10] :
```
  In a single-node environment, the controller runs all services. In a Packstack multi-node environment, the controller runs all services, but other nodes can run the compute service.
2. ```
Enter list of IP addresses on which to install compute service  [192.0.43.10] :
```
  If specifying more than one host, use a comma-separated list.
3. ```
Enter list of IP addresses on which to install network service  [192.0.43.10] :
```
  If specifying more than one host, use a comma-separated list. For a PoC installation, Red Hat recommends that the networking service be placed only on the controller node (default).

Do you want to use VMware vCenter as hypervisor and datastore [y|n] [n]:

```
Enable this on your own risk. Do you want to use insupported parameters [y|n]  [n] :
```
For a PoC installation, Red Hat recommends that insupported parameters be declined (default).
```
To subscribe each server to EPEL enter "y" [y|n]  [n] :
```
Packstack allows you to subscribe each server to Extra Packages for Enterprise Linux (EPEL). EPEL contains various packages from the Fedora development stream. Red Hat recommends that you decline EPEL subscription (default).
```
Enter a comma separated list of URLs to any additional yum repositories to install:
```
Packstack allows you to optionally configure each server to retrieve updates from additional custom software repositories. For basic installations, you do not need additional repositories; just click 'Enter'.
```
To subscribe each server to Red Hat enter a username here:
To subscribe each server with RHN Satellite enter RHN Satellite server URL:
To subscribe each server to Red Hat enter your password here:
```
Providing Red Hat subscription information ensures each server involved in the deployment is subscribed to receive updates from Red Hat Network.
Packstack allows you to optionally configure each server to retrieve updates from a Red Hat Network Satellite server instead of Subscription Manager. If you do not wish to use a Red Hat Satellite server, click 'Enter'.
Important
Packstack registers systems to Red Hat Network using Subscription Manager or Red Hat Network Satellite. You may encounter problems if your systems have already been registered and subscribed to the Red Hat OpenStack channels using RHN Classic.
If you provide a RHN Satellite URL, a number of follow up prompts will be displayed.
1. ```
Enter RHN Satellite username or leave plain if you will use activation key instead:
Enter RHN Satellite password or leave plain if you will use activation key instead:
```
  Red Hat Network Satellite supports authentication using a user name and password or an activation key. If your Satellite administrator provided you with a user name and password, enter them when prompted. If your Satellite administrator provided you with an access key, leave blank.
2. ```
Enter RHN Satellite activation key or leave plain if you used username/password instead :
```
  If your Satellite administrator provided you with an access key, specify it; otherwise, leave blank.
3. ```
Specify a path or URL to a SSL CA certificate to use:
```
  Specify the path to the certificate of the certificate authority that is used to verify that the connection with the Satellite server is secure.
4. ```
If required specify the profile name that should be used as an identifier for the system in RHN Satellite :
```
  Specify the optional profile name that must be used to identify the system in Red Hat Network.
5. ```
Specify a HTTP proxy to use with RHN Satellite:
```
  Specify the HTTP proxy for connecting to the Satellite server. If no proxy is required, leave blank.
6. ```
Specify a username to use with an authenticated HTTP proxy:
```
  Specify the user name for authenticating with the HTTP proxy to be used when connecting to the Satellite server. If no proxy is required or the chosen proxy does not require authentication, leave blank.
7. ```
Specify a password to use with an authenticated HTTP proxy.:
```
  Specify the password for authenticating with the HTTP proxy server that must be used when connecting to the Satellite server. If no proxy is required or the chosen proxy does not require authentication, leave blank.
8. ```
Enter comma separated list of flags passed to rhnreg_ks:
```
  Specify any additional Satellite flags that you need to be passed to the rhnreg_ks command when it is run on each system. This configuration key accepts a comma-separated list of flags. Valid flags are novirtinfo, norhnsd, and nopackages.
  See the Red Hat Satellite documentation for more information. If unsure, do not enter a value.
```
To enable RHEL optional repos use value "y" [y|n]  [y]:
```
A number of software packages required by OpenStack are kept in optional repositories; ensure that you enable these repositories (default).

Specify a HTTP proxy to use with Red Hat subscription manager:

If no proxy is required, leave blank.

Set the AMQP service backend [qpid|rabbitmq]  [rabbitmq] :
Enter the IP address of the AMQP service  [192.0.43.10] :
Enable SSL for the AMQP service? [y|n]  [n] :
Enable Authentication for the AMQP service? [y|n]  [n] :

The AMQP broker is the messaging technology used by OpenStack for communication between components. RabbitMQ is the recommended messaging system for PoC environments; by default, authentication and SSL are not enabled.

```
Enter the IP address of the MariaDB server [192.0.43.10] :
Enter the password for the MariaDB admin user :
```
OpenStack services require a MariaDB database for data storage. If you do not specify an existing database, a database is generated. After installation is complete, the generated password is available in Packstack's answer file.
```
Enter the password for the Keystone DB access:
Enter the password for the Keystone admin user :
Enter the password for the Keystone demo user :
```
When Packstack installs the Identity service, it automatically creates the Identity service database, and the:
- admin user, for management tasks, whose authentication information is stored in the /root/keystonerc_admin file. For multi-host installations, this file is located only on the CONFIG_OSCLIENT_HOST host. The admin password is also stored in Packstack's answer file.
- demo user (and tenant), for demonstration purposes, whose authentication information is stored in the /root/keystonerc_demo file.
```
Enter the password for the Glance DB access :
Enter the password for the Glance Keystone access :
```
When Packstack installs the Image service, it creates the Image service database and a 'glance' user. The Image service accesses the Identity service (keystone) as the glance user.
```
Glance storage backend [file|swift]  [file] :
```
Either the file system (default) or the Object Storage service (swift) can be used as a back end for the Image service.
When Packstack installs the Block Storage service, it creates the Block Storage database and a cinder user. The Block Storage service accesses the Identity service (keystone) as the cinder user.
1. ```
Enter the password for the Cinder DB access :
Enter the password for the Cinder Keystone access :
```
2. ```
Enter the Cinder backend to be configured [lvm|gluster|nfs|vmdk|netapp]  [lvm] :
```
  OpenStack Block Storage service uses a back end for storage; the default implementation uses Logical Volume Management (LVM) to create a Logical Volume Group called cinder-volumes. Alternatives are Red Hat Storage (gluster), Network File System (nfs), VMware (vmdk), or NetApp.
  - If you specify LVM, Packstack expects storage to be available on a volume group named cinder-volumes.
    Should Cinder's volumes group be created (for proof-of-concept installation)? [y|n] [y]:
    If the volume group does not already exist, you are asked if you want it to be created automatically. If you answer 'yes', Packstack creates a raw disk image in the /var/lib/cinder and mounts it using a loopback device.
    Enter Cinder's volumes group size [20G] :
    If you elected to have the cinder-volumes volume group created for you, you are also prompted to enter its size in gigabytes (GB).
    Important
    The specified amount of space must be available on the device used for /var/lib/cinder.
    Remember that the size of the volume group will restrict the amount of disk space that you can expose to Compute instances.
  - If you specify Red Hat Storage (gluster), you must specify the gluster volume to mount instead of a local volume. For example: ip-address:/vol-name
```
Enter a single or comma separated list of gluster volume shares to use with Cinder [^'([\d]{1,3}\.){3}[\d]{1,3}:/.*']:
```
  - If you specify NFS, you must specify a list of NFS exports to mount. For example: ip-address:/export-name
```
Enter a single or comma seprated list of NFS exports to use with Cinder [^([\d]{1,3}\.){3}[\d]{1,3}:/.*]:
```
  - If you specify NetApp, you must specify a user login, password, and host to access the NetApp server.
```
Enter a NetApp login []:							
Enter a NetApp password :
Enter a NetApp hostname:
```
When Packstack installs the Compute service, it creates a Compute database and a nova user. The Compute service accesses the Identity service (keystone) as the 'nova' user.
1. ```
Enter the password for the Nova DB access :
Enter the password for the Nova Keystone access :
```
2. ```
Enter the CPU overcommitment ratio. Set to 1.0 to disable CPU overcommitment[16.0]:
Enter the RAM overcommitment ratio. Set to 1.0 to disable RAM overcommitment[1.5]:
```
  In the default configuration, Compute allows for overcommitment of physical CPU and memory resources. This means that more of these resources are made available for running instances than actually physically exist on the compute node.
  The default level of CPU overcommitment allows 16 virtual CPUs to be allocated for each physical CPU socket or core that exists on the physical compute node. The default level of memory overcommitment allows up to 50% more virtual memory to be allocated than exists on the physical compute node.
3. ```
Enter protocol which will be used for instance migration [tcp|ssh]  [tcp]:
```
  By default, tcp is used for instance migration (recommended for security reasons):
4. ```
Enter the compute manager for nova migration  [nova.compute.manager.ComputeManager]
```
  Use the default value for the migration manager:
5. ```
Enter the Private interface for Flat DHCP on the Nova compute servers  [eth1]:
```
  Specify the private interface to provide DHCP services on the compute nodes.
6. ```
Enter the Nova network manager  [nova.network.manager.FlatDHCPManager]:
```
  Replace the final term Manager In the expression nova.network.manager.Manager, with VlanManager, FlatManager, or FlatDHCPManager. Flat DHCP is the default.
7. ```
Enter the Public interface on the Nova network server  [eth0]:
```
  Specify a public interface to use for connections from other nodes and clients. Examples: eth0 or plp1
8. ```
Enter the Private interface for Flat DHCP on the Nova network server  [eth1]:
```
  Specify the private interface to provide DHCP services on the compute network server.
9. ```
Enter the IP Range for network manager [192.168.32.0/22]:
```
  All compute instances are automatically assigned a private IP address. Specify the range from which these private IP addresses must be assigned.
10. ```
Enter the IP Range for Floating IP's [10.3.4.0/22]:
```
  Compute instances can optionally be assigned publicly accessible floating IP addresses. Specify the range from which floating IP addresses will be assigned.
11. ```
What should the default floating pool be called?  [nova]:
```
12. ```
Should new instances automatically have a floating IP assigned? [y|n]  [n] :
```
  All compute instances are assigned an internal IP address. Enter y to automatically assign floating point IP addresses (external addresses).
```
Would you like to set up Horizon communication over https [y|n]  [n] :
```
By default, the dashboard (horizon) is only set up with HTTP access; however, you can also set up secure HTTPS communication.
When Packstack installs OpenStack Networking, it creates the OpenStack Networking service database and a neutron user. OpenStack Networking accesses the Identity service (keystone) as the neutron user.
1. ```
Enter the password for the Neutron Keystone access :
Enter the password for Neutron DB access :
```
2. ```
Enter the ovs bridge the Neutron L3 agent will use for external traffic, or 'provider' if using provider networks.  [br-ex] :
```
  The Neutron L3 agent uses this OpenStack Networking bridge for external traffic, giving the node it is running on access to external address (for example, the Internet). There is no specific naming convention but it is recommended to give the bridge a meaningful name. By default, the external bridge is named br-ex. If you intend to use a provider network to handle external traffic, enter the special value provider.
3. ```
Enter Neutron metadata agent password :
```
  Specify the password for OpenStack Networking's metadata agent (proxies metadata requests from instances).
4. ```
Should Packstack install Neutron LBaaS [y|n]  [n] :
```
  Specify whether to use Load Balancing as a Service; only use this for multi-node installations.
5. ```
Should Packstack install Neutron L3 Metering agent [y|n]  [n] :
```
  Specify whether L3 agents should be metered.
6. ```
Would you like to configure neutron FWaaS? [y|n]  [n] :
```
  Specify whether to use OpenStack Networking's Firewall-as-a-Service.
7. ```
Enter a comma separated list of network type driver entrypoints [local|flat|vlan|gre|vxlan]  [vxlan] :
```
  Specify the network types from which OpenStack Networking can accept incoming traffic (port connections that support multi-segmented network environments).
8. ```
Enter the type of network to allocate for tenant networks [local|vlan|gre|vxlan]  [vxlan] :
```
  OpenStack Networking allocates tenant networks. Enter the type of network to allocate to the tenant networks.
  The use of local tenant networks is recommended for all-in-one deployments. The use of vlan tenant networks is recommended for multi-node deployments. The Open vSwitch Neutron plugin supports GRE tunneling, and you can select gre as long as the installed kernel (version 2.6.32-431.el6.x86_64 or later) and Open vSwitch userspace support GRE tunneling too.
9. ```
Enter a comma separated ordered list of networking mechanism driver entrypoints [logger|test|linuxbridge|openvswitch|hyperv|ncs|arista|cisco_nexus|l2population]  [openvswitch] :
```
  Specify the L2 mechanism driver entry points.
10. ```
Enter a comma separated  list of physical_network names with which flat networks can be created  [*] :
```
  Specify a list of names for flat networks; use * to allow flat networks with arbitrary physical network names (default).
11. ```
Enter a comma separated list of physical_network names usable for VLAN:
```
  Specify a list of names for VLAN provider and tenant networks. The syntax is for a name is: physical_network:vlan_min:vlan_max or physical_network
12. ```
Enter a comma separated list of <tun_min>:<tun_max> tuples enumerating ranges of GRE tunnel IDs that are available for tenant network allocation:
```
  Specify a list of tun_min:tun_max tuples enumerating ranges of GRE tunnel IDs that are available for tenant network allocation. A tuple must be an array with: tun_max +1 - tun_min > 1,000,000
13. ```
Enter a multicast group for VXLAN:
```
  The group value must be a multicast IP (v4 or v6) address. If not set, disables VXLAN from sending allocated broadcast traffic to this multicast group (disables multicast VXLAN mode).
14. ```
Enter a comma separated list of <vni_min>:<vni_max> tuples enumerating ranges of VXLAN VNI IDs that are available for tenant network allocation  [10:100] :
```
  Specify available VXLAN IDs; minimum value is 0; maximum value is 16777215.
15. ```
Enter the name of the L2 agent to be used with Neutron [linuxbridge|openvswitch]  [openvswitch] :
```
16. ```
Enter a comma separated list of bridge mappings for the Neutron openvswitch plugin:
```
  Specify a list of bridge mappings for the OpenStack Networking Open vSwitch plugin. Each tuple in the list is expected to be in the format PHYSICAL:BRIDGE. Replace PHYSICAL with the name of a network, and replace BRIDGE with the name of the Open vSwitch bridge that will be used to connect to the network.
  Continuing the example above, with physnet1 using the interface called "br-eth1", you could use the default option so physnet1 consists of VLANs 1 to 1000 on bridge br-eth1 (physnet1:br-eth1).
17. ```
Enter a comma separated list of OVS bridge:interface pairs for the Neutron openvswitch plugin:
```
  Specify a list of bridge interface pairs; the interface is added to the associated bridge.
18. ```
Enter interface with IP to override the default tunnel local_ip:
```
  Specify the interface for the OVS tunnel; Packstack uses this value to override the IP address used for tunnels on the hypervisor to the IP found on the specified interface (for example, eth1).
19. ```
Enter VXLAN UDP port number  [4789] :
```
```
Enter the IP address of the client server  [192.0.43.10] :
```
Specify the IP address of the server on which to install the client tools. An "rc" file containing administrative credentials will also be created on this host.
```
Would you like to set up Horizon communication over https [y|n]  [n] :
```
OpenStack uses the dashboard service (horizon) to provide a web-based user interface for accessing OpenStack services. Specifying y ensures that your access to the dashboard is encrypted.
When Packstack installs the Object Storage service, it creates the swift user (with which the Object Storage service accesses the Identity service).
1. ```
Enter the password for the Swift Keystone access :
```
2. ```
Enter the Swift Storage devices e.g. /path/to/dev:
```
  Specify a comma-separated list of devices for Object Storage to use for storage. Each entry must take the format /path/to/dev (for example, /dev/vdb). Packstack does not create the filesystem, you must create it first. If the value is omitted, Packstack creates a loopback device for a test setup.
3. ```
Enter the number of swift storage zones, MUST be no bigger than the number of storage devices configured  [1] :
```
  Object Storage uses zones to ensure that each replica of a given object is stored separately. A zone might represent an individual disk drive or array, a server, all the servers in a rack, or even an entire data center. The number provided must not be bigger than the number of individual devices specified in the previous step.
4. ```
Enter the number of swift storage replicas, MUST be no bigger than the number of storage zones configured  [1] :
```
  Specify the number of replicas to keep of each object. Object Storage relies on replication to maintain the state of objects even in the event of a storage outage in one or more of the configured storage zones.
  A minimum of three (3) replicas is recommended to ensure a reasonable degree of fault tolerance in the object store. However, the number of replicas specified must not be greater than the number of storage zones because this would result in one or more of the zones containing multiple replicas of the same object.
5. ```
Enter FileSystem type for storage nodes [xfs|ext4]  [ext4] :
```
  Specify the file system type to be used by Object Storage. Packstack supports the use of either Ext4 or XFS file systems for object storage. The default and recommended choice is Ext4.
6. ```
Enter the size of the storage device (eg. 2G, 2000M, 2000000K)  [2G] :
```
  Specify the size of the loopback file-storage device.
When Packstack installs the Orchestration service, it creates the Orchestration service database and a heat user. OpenStack Orchestration accesses the Identity service (keystone) as the heat user.
1. ```
Enter the password for the Heat MySQL user :
Enter the password for the Heat Keystone access :
```
2. ```
Should Packstack install Heat CloudWatch API [y|n]  [n] :
Should Packstack install Heat CloudFormation API [y|n]  [n] :
```
  Specify whether the CloudWatch (metrics collection) and CloudFormation APIs should be installed . Orchestration provides compatibility with the AWS CloudFormation template format, so that many existing CloudFormation templates can be launched on OpenStack. Orchestration provides both an OpenStack-native REST API and a CloudFormation-compatible Query API.
3. ```
Enter name of Keystone domain for Heat  [heat] :
```
  Specify where to place Orchestration stacks.
4. ```
Enter name of Keystone domain admin user for Heat  [heat_admin] :
Enter password for Keystone domain admin user for Heat :
```

Packstack can install the OpenStack Integration test suite, Tempest, for testing. Tempest runs tests using a simple configuration file that describes the test environment. The tests are run against all OpenStack service endpoints by exercising API calls and validating the responses.

Note

The testing environment can only be installed if OpenStack Networking is installed, together with namespaces.

Would you like to provision for demo usage and testing? [y|n]  [y] :

Specify whether you would like install the testing suite.

Would you like to configure Tempest (OpenStack test suite). Note that provisioning is only supported for all-in-one installations. [y|n]  [n] : n

Enter the name of the Tempest Provisioning user (if blank, Tempest will be configured in a standalone mode) :  
Enter the password for the Tempest Provisioning user :

Enter the network address for the floating IP subnet:  [192.168.32.0/22] :

Specify a network address for the demo floating IP subnet.

Enter the URL or local file location for the Cirros image  [http://download.cirros-cloud.net/0.3.3/cirros-0.3.3-x86_64-disk.img] :

Specify the URL of an image to be automatically uploaded into the Image service for use by instances.

What is the uri of the Tempest git repository?  [https://github.com/openstack/tempest.git] :

What revision, branch, or tag of the Tempest git repository should be used  [master] :

```
Would you like to configure the external ovs bridge? [y|n]  [n] :
```
For the demo user and testing, would you like to configure the external OVS bridge.

```
Enter the password for the Ceilometer Keystone access :
```
When Packstack installs the Telemetry service, it creates the ceilometer user, with which it accesses the Identity service (keystone). Specify the access password for the ceilometer user:

Enter the IP address of the MongoDB server  [192.0.43.10] : 
Enter the IP address of the redis server  [192.0.43.10] : 
Enter the port of the redis server  [6379] :

The MongoDB and Redis servers are used for clustering and replication support for OpenStack Database-as-a-Service (trove).

Enter the password for the nagiosadmin user :

At this point, you are asked to confirm the deployment details that you provided. Type yes and press Enter to continue with the deployment. For example:

Important

To change parameter values, you can:

Specify no; the installation starts again from Step 1, but this time the displayed defaults are the ones you had previously entered. You can now change the values of the parameters and continue with the installation.
Specify yes, and hit Ctrl-C after the installation begins. You can then modify the parameters in the answer file (packstack-answers-xxxx.txt) and re-run Packstack using the following command:
```
# packstack --answer-file=packstack-answers-xxxx.txt
```

Deployment time can be significant; Packstack provides continuous updates indicating which manifests are being deployed as it progresses. Once the process is completed, a confirmation message similar to the one below is displayed (depending on the options you chose):

**** Installation completed successfully ******
Additional information:
* A new answerfile was created in: /root/packstack-answers-20130613-133303.txt
* Time synchronization installation was skipped. Please note that unsynchronized time on server instances might be problem for some OpenStack components.
* To use the command line tools you need to source the file /root/keystonerc_admin created on 192.0.43.10
* To use the console, browse to http://192.0.43.10/dashboard
* To use Nagios, browse to http://192.0.43.10/nagios username : nagiosadmin, password: abcdefgh12345678
* Kernel package with netns support has been installed on host 192.0.43.10. Because of the kernel update host mentioned above requires reboot.
* The installation log file is available at: /var/tmp/packstack/20130613-133302-5UY8KB/openstack-setup.log

You have successfully deployed an OpenStack environment using Packstack. For next steps, see Chapter 4, Using OpenStack.

Warning

The answer file contains a number of required configuration values, including administrative passwords. It is recommended that you store the answer file in a secure location.

Unless specified, passwords are also generated for each service; for a complete password listing and update commands, refer to Appendix B, Passwords.