Openstack – Running PackStack Interactively

February 7, 2023 Uncategorized

OpenStack can be deployed by running PackStack interactively. PackStack supports the creation of both single node and multiple node OpenStack deployments.

Note

The procedure below lists all the questions that PackStack prompts you to answer. Based on the choices you make, some of these options might be skipped during the setup.

⁠

Procedure 5.3. Running PackStack Interactively

Running PackStackRun the packstack command to commence the deployment process. Optionally append the --debugparameter to enable additional logging.# packstackImportantYou are not required to log in as the root user to run the packstack command itself. However you will be required to provide root credentials for each machine to which you choose to deploy services.
Configuring the Public KeyEach server involved in the OpenStack deployment is configured for key-based authentication. If you already have a public key that you wish to use for this, enter the path to it. If you do not, then press Enterand the utility will generate one for you and save it to ~/.ssh/id_rsa.pub.Enter the path to your ssh Public key to install on servers:
Selecting the MySQL DatabasePackStack will prompt you to choose if you want to install MySQL database on the same host or on a remote host.Should Packstack install MySQL DB [y|n] [y] :NotePackStack is capable of installing a single MySQL database node. On the other hand, PackStack does not handle MySQL cluster installation, but it allows you to work with a MySQL cluster that you have set up separately.If you choose n, PackStack asks you for credentials and uses CONFIG_MYSQL_HOST as a given remote database.
Selecting the Services to InstallThe PackStack script will prompt you to select the OpenStack services that you want to install and configure. At each prompt enter y to install the service, enter n to skip the service, or press Enter to select the default option listed in square brackets ([, ]).Should Packstack install OpenStack Image service (Glance) [y|n] [y] : Should Packstack install OpenStack Block Storage service (Cinder) [y|n] [y] : Should Packstack install OpenStack Compute service (Nova) [y|n] [y] : Should Packstack install OpenStack Networking service (Neutron) [y|n] [y] : Should Packstack install OpenStack Dashboard service (Horizon) [y|n] [y] : Should Packstack install OpenStack Object Storage service (Swift) [y|n] [n] : Should Packstack install OpenStack Telemetry service (Ceilometer) [y|n] [y] : Should Packstack install Heat [y|n] [n] : NoteDepending on which services you selected for installation, the ensuing prompts in this procedure will vary.Each selected service can be deployed on either a local or remote system. Where each service deploys to will be determined based on the IP addresses you provide later in the deployment process.
OpenStack includes a number of client tools. Enter y to install the client tools. A file containing the authentication values of the administrative user will also be created.Should Packstack install OpenStack client tools [y|n] [y] :
Optionally, the PackStack script will configure all servers in the deployment to retrieve date and time information using Network Time Protocol (NTP). To use this facility enter a comma separated pool of NTP servers.Enter a comma separated list of NTP server(s). Leave plain if Packstack should not install ntpd on instances.:⁠Example 5.4. Using the Default Red Hat Enterprise Linux NTP ServersEnter 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
Optionally, the PackStack script will install and configure Nagios to provide advanced facilities for monitoring the nodes in the OpenStack environment.Should Packstack install Nagios to monitor openstack hosts [y|n] [n] :
If you have existing servers that have been configured previously, and you do not want PackStack to overwrite their configurations, you can specify the IP addresses of the servers to be excluded.Enter a comma separated list of server(s) to be excluded. Leave plain if you don’t need to exclude any server.:
Configuring the MySQL InstanceOpenStack services require a MySQL database to store data in. To configure the database:
1. Enter the IP address of the server to deploy the MySQL database server on.Enter the IP address of the MySQL server [192.0.43.10] :
2. Enter the password to use for the MySQL administrative user. If you do not enter a value it will be randomly generated. The generated password will be available both in the ~/.my.cnf file of the current user and in the answer file.Enter the password for the MySQL admin user :
Configuring QpidOpenStack services use the Qpid (http://qpid.apache.org/) messaging system to communicate. Enter the IP address of the server to deploy Qpid on.Enter the IP address of the QPID service [192.0.43.10] :
Configuring the Identity serviceOpenStack uses the Identity service (openstack-keystone) for identity, token, catalog, and policy services.
1. If Identity service installation was selected, then you must enter the IP address of the server to deploy Identity on.Enter the IP address of the Keystone server [192.0.43.10] :
2. A Keystone admin user is created when the Identity service is installed. This user requires a password. The password and other information is stored in the keystonerc_admin file, which is located in the /root directory. In case of multi-host installation, keystonerc_admin is located only in /root on the CONFIG_OSCLIENT_HOST host.The admin password is also stored in PackStack’s answer file.Enter the password for the Keystone admin user.Enter the password for the Keystone admin user :
3. A demo Keystone tenant is also created along with a keystonerc_demo file, which can be sourced like the existing keystonerc_admin file. Creating this user enables the keys CONFIG_PROVISION_DEMO and CONFIG_PROVISION_ALL_IN_ONE_OVS_BRIDGE in PackStack’s answer file. This answer file will have a file name similar to /root/packstack-answers-20130306-051043.txt.Enter the password for the Keystone demo user.Enter the password for the Keystone demo user :
Configuring the Image serviceOpenStack uses the Image service (openstack-glance-*) to store, discover, and retrieve virtual machine images. If Image service installation was selected then enter the IP address of the server to deploy Image service on when prompted.Enter the IP address of the Glance server [192.0.43.10] :
Configuring the Volume serviceOpenStack uses the Volume service (openstack-cinder-*) to provide volume storage services.
1. If Volume service installation was selected, enter the IP address of the server to deploy the Volume service on.Enter the IP address of the Cinder server [192.0.43.10] :
2. OpenStack Block Storage requires some back-end storage that the service is built on. The default implementation is to use Logical Volume Management (LVM) to create a Logical Volume Group called cinder-volumes. Alternatives are Red Hat Storage (gluster) or Network File System (NFS).Enter the Cinder backend to be configured [lvm|gluster|nfs] [lvm]:
3. If you chose LVM, PackStack expects storage for use with Volume to be available on a volume group named cinder-volumes.
  1. If this volume group does not already exist then you will be asked if you want it to be created automatically.Answering yes means that PackStack will create a raw disk image in the /var/lib/cinder and mount it for use by Volume using a loopback device.Should Cinder’s volumes group be created (for proof-of-concept installation)? [y|n] [y]:
  2. If you elected to have PackStack create the cinder-volumes volume group for you then you will be prompted to enter the size of it in gigabytes (GB).Enter Cinder’s volumes group size [20G] :ImportantThe amount of space selected must be available on the device used for /var/lib/cinder.Remember that the size of the Volume service’s volume group will restrict the amount of disk space that you can expose to Compute instances.
4. If you chose gluster, you do not need to create a local volume. Instead you need to choose the gluster volume to mount.
  1. Enter a gluster volume for use with Cinder, 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}:/.*’]:
Configuring the Compute serviceCompute is made up of a number of complementary services that must be deployed. If installation of the Compute services was selected then these additional configuration prompts will be presented.
1. The Compute API service (openstack-nova-api) provides web service endpoints for authenticating and interacting with the OpenStack environment over HTTP or HTTPS. Enter the IP address of the server to deploy the Compute API service on.Enter the IP address of the Nova API service [192.0.43.10] :
2. Compute includes a certificate management service (openstack-nova-cert). Enter the IP address of the server to deploy the Compute certificate management service on.Enter the IP address of the Nova Cert service [192.0.43.10] :
3. The Compute VNC proxy provides facilities for connecting users of the Compute service to their instances running in the OpenStack cloud. Enter the IP address for the server to deploy the Compute VNC proxy on.Enter the IP address of the Nova VNC proxy [192.0.43.10] :
4. The PackStack script is able to deploy one or more Compute nodes. Enter a comma separated list containing the IP addresses or hostnames of all of the nodes that you wish to deploy Compute services on.Enter a comma separated list of IP addresses on which to install the Nova Compute services [192.0.43.10] :
5. The Conductor service (openstack-nova-conductor) provides database query support to the Compute service. Enter the IP address of the server to deploy the Conductor service on.Enter the IP address of the Nova Conductor service [192.0.43.10]:
6. The Compute scheduler (openstack-nova-scheduler) is used to map Compute’s requests to Compute resources. Enter the IP address of the server to deploy the Compute scheduler on.Enter the IP address of the Nova Scheduler service [192.0.43.10] :
7. 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 amount of overcommitment that is permitted is configurable.
  1. 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. Press Enter to accept the default or enter a different value if desired.Enter the CPU overcommitment ratio. Set to 1.0 to disable CPU overcommitment [16.0] :
  2. The default level of memory overcommitment allows up to 50% more virtual memory to be allocated than exists on the physical Compute node. Press Enter to accept the default or enter a different value if desired.Enter the RAM overcommitment ratio. Set to 1.0 to disable RAM overcommitment [1.5] :
8. A private interface must be configured to provide DHCP services on the Compute nodes. Enter the name of the private interface to use.Enter the Private interface for Flat DHCP on the Nova compute servers [eth1] :
9. The Compute networking service (openstack-nova-network) provides network services for Compute instances. Enter the IP address of the server to deploy the Compute networking service on.Enter the IP address of the Nova Network service [192.0.43.10] :ImportantThe Compute networking service is incompatible with the OpenStack Network service added since the Folsom release.
10. The Compute network manager can be selected to be VLAN Manager, Flat Manager or Flat DHCP manager. Type VlanManager, FlatManager, or FlatDHCPManager to replace the final term Manager in the expression nova.network.manager.Manager as required. Flat DHCP is the default.Enter the Nova network manager [nova.network.manager.FlatDHCPManager] :
11. A public interface must be configured to allow connections from other nodes and clients. Enter the name of the public interface to use.Enter the Public interface on the Nova network server [eth0] :
12. A private interface must be configured to provide DHCP services on the Compute network server. Enter the name of the private interface to use.Enter the Private interface for Flat DHCP on the Nova network server [eth1] :
13. All Compute instances are automatically assigned a private IP address. Enter the range from which these private IP addresses must be assigned.Enter the IP Range for network manager [192.168.32.0/22] :
14. Compute instances can optionally be assigned publicly accessible floating IP addresses. Enter the range from which floating IP addresses will be assigned.Enter the IP Range for Floating IP’s [10.3.4.0/22] :
15. The default floating pool needs to be named. Enter the name for the default floating poolWhat should the default floating pool be called? [nova] :
16. All Compute instances are assigned a floating point IP. Enter y to automatically assign floating point IP address.Should new instances automatically have a floating IP assigned? [y|n] [n] :
Configuring OpenStack NetworkingOpenStack Networking service provides a scalable and API-driven system for managing the network connectivity, addressing, and services within an OpenStack IaaS cloud deployment.
1. Enter the IP address of the OpenStack Networking Server.Enter the IP address of the Neutron server [192.0.43.10] :
2. OpenStack Networking uses namespaces (netns).The OpenStack Networking namespaces virtualize access to network resources, giving each group of processes the network access it requires. The groups of processes are referred to as containers. Red Hat Enterprise Linux OpenStack Platform includes a custom Red Hat Enterprise Linux kernel that supports the use of network namespaces.ImportantThis kernel must be installed on all OpenStack nodes. Additionally, the Open vSwitch plug-in requires a kernel with the version 2.6.32-431.el6.x86_64 or later.Enter y to select the use of namespaces.Should Neutron use network namespaces? [y|n] [y] :
3. OpenStack Networking sets up the Neutron L3 agent.The L3 agent acts as an abstract L3 router that can connect to and provide gateway services for multiple L2 networks. Usually the L3 agent will run on the network node. If there is no network node it should run on the controller node. The nodes on which the L3 agent will be hosted must have a range of IP addresses from the external network that are available for use by OpenStack Networking. These IP addresses will be assigned to the routers that provide the link between the internal and external networks.Enter the IP addresses on which the Neutron L3 Agent should be set up.NoteThe range selected must be large enough to provide a unique IP address for each router in the deployment as well as each desired floating IP.Enter a comma separated list of IP addresses on which to install the Neutron L3 agent [192.0.43.10]
4. In order to have OpenStack Networking set up a bridge for external traffic, you need to specify a name for this bridge. The Neutron L3 agent will use this bridge for external traffic, giving the node it is running on access to, for example, the internet. There is no specific naming convention but it is recommended to give the bridge a meaningful name. If you do not enter a name, the external bridge will by default be named br-ex. If you intend to use a provider network to handle external traffic, enter the special value provider.Enter the name of the bridge that the Neutron L3 agent will use for external traffic [br-ex]
5. OpenStack Networking sets up the Neutron DHCP agent.This agent is capable of allocating IP addresses to virtual machines running on the network. The DHCP agent runs on the network node. If there is no network node the DHCP agent should run on the controller node. Enter the list of IP addresses on which you want Neutron DHCP set up.Enter a comma separated list of IP addresses on which to install Neutron DHCP agent [192.0.43.10] :
6. Enter the name of the L2 plugin to be used with OpenStack Networking. Valid options are:
  - linuxbridge: Choose this option if you need a simple bridge and do not require support for VLANs or GRE.
  - openvswitch: Choose this option if you wish to have configurable ports on a managed switch or will require VLAN or GRE support.
  Enter the name of the L2 plugin to be used with Neutron [linuxbridge|openvswitch] [openvswitch] :
7. The OpenStack Compute service allows VMs to query metadata associated with a VM by making a web request to a special IP address. OpenStack Networking supports proxying those requests to nova-api, even when the requests are made from isolated networks, or from multiple networks that use overlapping IP addresses. In order to use this functionality, OpenStack Networking must install the metadata agent. Enter the IP addresses on which the metadata agent should be set up.Enter a comma separated list of IP addresses on which to install the Neutron metadata agent [192.0.43.10] :
8. 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.Enter the type of network to allocate for tenant networks [local|vlan|gre] [local] :
9. Enter a list of VLAN ranges for use with the selected plug-in.Each tuple in the list is expected to be in the format PHYSICAL:START:END. Note that PHYSICAL is just a user-provided label for a network name, not necessarily a physical device. Replace PHYSICAL with the name of a network, replace START with the start of the VLAN range to identify with it, and replace END with the end of the VLAN range to associate with it.For example, with a network called “physnet1” that has a VLAN range from 1 to 1000, you would specify “physnet1:1:1000”.Enter a comma separated list of VLAN ranges for the Neutron openvswitch plugin:
10. Enter 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.Enter a comma separated list of bridge mappings for the Neutron openvswitch plugin [physnet1:br-eth1] :
Configuring Client ToolsIf installation of the client tools was selected then enter the IP address of the server to install the client tools on when prompted.Enter the IP address of the client server [192.0.43.10] :An “rc” file containing administrative credentials will also be created on this host.
Configuring the DashboardOpenStack uses the Dashboard service (openstack-dashboard) to provide a web-based user interface or Dashboard for accessing OpenStack services including Volume, Compute, Object Storage, and Identity. If installation of the Dashboard was selected then these additional configuration values will be requested.
1. Enter the IP address of the server to deploy Dashboard on.Enter the IP address of the Horizon server [192.0.43.10] :
2. To enable HTTPS communication with the Dashboard enter y when prompted. Enabling this option ensures that your access to the Dashboard is encrypted.Would you like to set up Horizon communication over https [y|n] [n] :
Configuring Object StorageIf installation of Object Storage was selected then these additional configuration values will be requested.
1. Enter the IP address of the server that is to act as the Object Storage proxy. This server will act as the public link between clients and the Object Storage.Enter the IP address of the Swift proxy service [192.0.43.10] :
2. Enter a comma separated list of devices that Object Storage will use to store objects. Each entry must be specified in HOST/DEVICE format where HOST is replaced by the IP address of the host the device is attached to, and DEVICE is replaced by the path to the device.Enter the Swift Storage servers e.g. host/dev,host/dev [192.0.43.10] :
3. 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.When prompted enter the number of storage zones that must be defined. Note that the number provided must not be bigger than the number of individual devices specified.Enter the number of swift storage zones, MUST be no bigger than the number of storage devices configured [1] :
4. 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. Enter the number of replicas that Object Storage must keep of each object when prompted.A minimum of three (3) replicas is recommended to ensure a reasonable degree of fault tolerance in the object store. Note however that the number of replicas specified must not be greater than the number of storage zones as this would result in one or more of the zones containing multiple replicas of the same object.Enter the number of swift storage replicas, MUST be no bigger than the number of storage zones configured [1] :
5. Currently PackStack supports the use of either Ext4 or XFS filesystems for object storage. The default and recommended choice is Ext4. Enter the desired value when prompted.Enter FileSystem type for storage nodes [xfs|ext4] [ext4] :
Configuring Demo a User and TestingPackStack allows you to provision a demo user and a testing suite.
1. PackStack allows you to optionally configure a demo user and testing. Select y or n to make your choice.Would you like to provision for demo usage and testing? [y|n] [n] :
2. If you choose to provision a demo user, then enter a network address for the floating IP subnet.Enter the network address for the floating IP subnet: [192.168.32.0/22] :
3. Tempest is the OpenStack Integration test suite. It 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 validates the responses.If you choose to configure the demo user and testing, would you like to configure the OpenStack test suite.Would you like to configure Tempest (OpenStack test suite)? [y|n] [n] :
4. For the demo user and testing, would you like to configure the external OVS bridge.Would you like to configure the external ovs bridge? [y|n] [n] :
Configuring the Orchestration ServiceThe Orchestration service provides a template-based orchestration for describing a cloud application by running OpenStack API calls to generate running cloud applications. The software integrates other core components of OpenStack into a one-file template system.
1. The CloudWatch API can be used to do the following functionality: list alarms, list metrics etc. Enter yto install the Heat CloudWatch API.Should Packstack install Heat CloudWatch API [y|n] [n] :
2. Heat endeavors to provide compatibility with the AWS CloudFormation template format, so that many existing CloudFormation templates can be launched on OpenStack. Heat provides both an OpenStack-native REST API and a CloudFormation-compatible Query API. Enter y to install Heat CloudFormation API.Should Packstack install the Heat CloudFormation API [y|n] [n] :
NoteFor more information on how to use the Dashboard and CLI commands to create and manage stacks using templates, see the section Launch and manage stacks in the Red Hat Enterprise Linux OpenStack Platform 4 End User Guide guide.
Configuring the Telemetry ServiceThe Telemetry service is the unique point of contact for billing systems to acquire all of the measurements they need to establish customer billing, across all current OpenStack core components. Enter the IP address of the server on which the Telemetry service has to be installed.Enter the IP address of the Ceilometer server [192.0.43.10] :NoteThe Telemetry service for the Dashboard is only an admin function for RHEL OpenStack Platform 4.0. For more information on the CLI commands to use the Telemetry commands, see the section Measure cloud resources in the Red Hat Enterprise Linux OpenStack Platform 4 End User Guideguide.
Configuring EPELPackStack allows you to subscribe each server to Extra Packages for Enterprise Linux (EPEL).To subscribe each server to EPEL enter “y” [y|n] [n] :
Configuring Software SourcesPackStack allows you to configure the target servers to retrieve software packages from a number of sources.
1. Enabling Custom Software RepositoriesPackStack allows you to optionally configure each server to retrieve updates from additional custom software repositories. Enter the URL for the directory containing the repodata folder of each desired repository at the prompt, separated by a comma.Enter a comma separated list of URLs to any additional yum repositories to install:
2. Enabling Red Hat Network SubscriptionEnter your Red Hat Network account details when prompted. This will ensure each server involved in the deployment is subscribed to receive updates from Red Hat Network.To subscribe each server to Red Hat enter a username here:To subscribe each server to Red Hat enter your password here:ImportantPackStack 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.
3. Enabling the Red Hat Enterprise Linux Beta ChannelTo enable the Red Hat Enterprise Linux Beta channel enter y when prompted. Note that selecting this option is not recommended at this time but may be required by future Red Hat Enterprise Linux OpenStack Platform preview releases.To subscribe each server to Red Hat Enterprise Linux 6 Server Beta channel (only needed for Preview versions of RHOS) enter “y” [y|n] [n] :
4. Enabling Red Hat Network SatellitePackStack allows you to optionally configure each server to retrieve updates from a Red Hat Network Satellite server.Enter the URL of the Red Hat Network Satellite server that you wish to use when prompted. If you do not wish to use a Red Hat Satellite server then do not enter a value.To subscribe each server with RHN Satellite enter RHN Satellite server URL :If an RHN Satellite URL is provided a number of follow up prompts will be displayed.
  1. 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 then do not enter a value.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 :
  2. If your Satellite administrator provided you with an access key then enter it when prompted. Otherwise do not enter a value.Enter RHN Satellite activation key or leave plain if you used username/password instead :
  3. Specify the path to the certificate of the certificate authority that is used to verify that the connection with the Satellite server is secure.Specify a path or URL to a SSL CA certificate to use :
  4. Specify the profile name that must be used to identify the system in Red Hat Network. This is optional.If required specify the profile name that should be used as an identifier for the system in RHN Satellite :
  5. Specify the HTTP proxy that must be used when connecting to the Satellite server. If no proxy is required then do not enter a value.Specify a HTTP proxy to use with RHN Satellite :
  6. Specify the user name for authenticating with the HTTP proxy that must be used when connecting to the Satellite server. If no proxy is required or the chosen proxy does not require authentication then do not enter a value.Specify a username to use with an authenticated HTTP proxy :
  7. 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 then do not enter a value.Specify a password to use with an authenticated HTTP proxy. :
  8. 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.Refer to the Red Hat Satellite documentation for more information. If unsure do not enter a value.Enter comma separated list of flags passed to rhnreg_ks :
Verify Parameters and ConfirmAt this point you will be asked to confirm the deployment details that you provided. Type yes and press Enter to continue with the deployment.Depending on the options you chose, the following screen’s content will vary.Installer will be installed using the following configuration: ============================================================== ssh-public-key: /root/.ssh/id_rsa.pub os-mysql-install: y os-glance-install: y os-cinder-install: y os-nova-install: y os-neutron-install: y os-horizon-install: y os-swift-install: n os-ceilometer-install: y os-heat-install: n os-client-install: y ntp-servers: nagios-install: n exclude-servers: mysql-host: 192.0.43.10 mysql-pw: ******** qpid-host: 192.0.43.10 qpid-enable-ssl: n keystone-host: 192.0.43.10 keystone-admin-passwd: ******** keystone-demo-passwd: ******** glance-host: 192.0.43.10 cinder-host: 192.0.43.10 cinder-backend: lvm cinder-volumes-create: y cinder-volumes-size: 20G novaapi-host: 192.0.43.10 novacert-host: 192.0.43.10 novavncproxy-hosts: 192.0.43.10 novacompute-hosts: 192.0.43.10 novaconductor-host: 192.0.43.10 nova-db-passwd: ******** nova-ks-passwd: ******** novasched-host: 192.0.43.10 novasched-cpu-allocation-ratio:16.0 novasched-ram-allocation-ratio:1.5 novacompute-privif: eth1 novanetwork-host: 192.0.43.10 novanetwork-pubif: eth0 novanetwork-privif: eth1 novanetwork-fixed-range: 192.168.32.0/22 novanetwork-floating-range: 10.3.4.0/22 novasched-host: 192.0.43.10 novasched-cpu-allocation-ratio:16.0 novasched-ram-allocation-ratio:1.5 neutron-server-host: 192.0.43.10 neutron-use-namespaces: y neutron-l3-hosts: 192.0.43.10 neutron-l3-ext-bridge: br-ex neutron-dhcp-hosts: 192.0.43.10 neutron-l2-plugin: openvswitch neutron-metadata-hosts: 192.0.43.10 neutron-ovs-tenant-network-type:local neutron-ovs-vlan-ranges: neutron-ovs-bridge-mappings: physnet1:1000:2000 osclient-host: 192.0.43.10 os-horizon-host: 192.0.43.10 os-horizon-ssl: n provision-demo: n provision-demo-floatrange: 192.168.32.0/22 provision-tempest: n provision-all-in-one-ovs-bridge:n os-heat-cloudwatch-install: n os-heat-cfn-install: n ceilometer-host: 192.0.43.10 use-epel: n os-swift-proxy: 192.0.43.10 os-swift-storage: 192.0.43.10 os-swift-storage-zones: 1 os-swift-storage-replicas: 1 os-swift-storage-fstype: ext4 additional-repo: rh-username: [email protected] rh-password: ******** rhn-satellite-server: Proceed with the configuration listed above? (yes|no): yesImportantAt this stage, if you need to change any of the parameter values there are two ways to do so.
- Choose no, the installation then starts from Step 1 prompting you to enter values from the beginning, but this time the default values displayed are the ones you had previously entered. You can now change the values of the parameters and complete the installation by choosing yeswhen prompted, after the screen of new parameters is displayed.
- Choose yes, the installation begins and an answer file is created. But this could result in error if there is an issue with the parameters. You can then modify the parameters in the answer file (packstack-answers-xxxx.txt) and re-run with the following command.# packstack --answer-file=packstack-answers-xxxx.txt
At this point PackStack will commence deployment. Note that when PackStack is setting up SSH keys it will prompt you to enter the root password to connect to machines that are not already configured to use key authentication.Depending on the options you chose, the following screen’s content will vary.Installing: Clean Up… [ DONE ] Setting up ssh keys… [ DONE ] Discovering hosts’ details… [ DONE ] Disabling NetworkManager… [ DONE ] Adding pre install manifest entries… [ DONE ] Adding MySQL manifest entries… [ DONE ] Adding QPID manifest entries… [ DONE ] Adding Keystone manifest entries… [ DONE ] Adding Glance Keystone manifest entries… [ DONE ] Adding Glance manifest entries… [ DONE ] Installing dependencies for Cinder… [ DONE ] Adding Cinder Keystone manifest entries… [ DONE ] Adding Cinder manifest entries… [ DONE ] Checking if the Cinder server has a cinder-volumes vg… [ DONE ] Creating Cinder manifest… [ DONE ] Adding Nova API manifest entries… [ DONE ] Adding Nova Keystone manifest entries… [ DONE ] Adding Nova Cert manifest entries… [ DONE ] Adding Nova Conductor manifest entries… [ DONE ] Adding Nova Compute manifest entries… [ DONE ] Adding Nova Network manifest entries… [ DONE ] Adding Nova Scheduler manifest entries… [ DONE ] Adding Nova VNC Proxy manifest entries… [ DONE ] Adding Nova Common manifest entries… [ DONE ] Adding Openstack Network-related Nova manifest entries…[ DONE ] Adding Neutron API manifest entries… [ DONE ] Adding Neutron Keystone manifest entries… [ DONE ] Adding Neutron L3 manifest entries… [ DONE ] Adding Neutron L2 Agent manifest entries… [ DONE ] Adding Neutron DHCP Agent manifest entries… [ DONE ] Adding Neutron Metadata Agent manifest entries… [ DONE ] Adding OpenStack Client manifest entries… [ DONE ] Adding Horizon manifest entries… [ DONE ] Adding Ceilometer manifest entries… [ DONE ] Adding Ceilometer Keystone manifest entries… [ DONE ] Adding post install manifest entries… [ DONE ] Preparing Servers… [ DONE ] Adding post install manifest enries… [ DONE ] Installing Dependencies… [ DONE ] Copying Puppet modules and manifests… [ DONE ] Applying Puppet manifests…
Applying the Puppet manifests to all machines involved in the deployment takes a significant amount of time. PackStack provides continuous updates indicating which manifests are being deployed as it progresses through the deployment process. Once the process completes a confirmation message similar to the one shown below will be displayed.Depending on the options you chose, the following screen’s content will vary. **** Installation completed successfully ****** (Please allow Installer a few moments to start up…..) 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 mail in /var/spool/mail/root
Reboot all the nodes in the environment to ensure that the kernel change takes effect.PackStack deploys a new kernel with network namespaces enabled for all the nodes. You must reboot the environment to ensure that the change takes effect.# reboot

You have successfully deployed OpenStack using PackStack.

The configuration details that you provided are also recorded in an answer file that can be used to recreate the deployment in future. The answer file is stored in the /root directory, and is given a file name containing the date and time, for example /root/packstack-answers-20140214-133303.txt.

Openstack – Running PackStack Interactively

LEAVE A COMMENT Cancel reply

Recent Posts

Recent Comments