Deploying OpenStack: Enterprise Environments (Red Hat Enterprise Linux OpenStack Platform Installer)
Deploying Red Hat Enterprise Linux OpenStack Platform in an enterprise environment
Legal Notice
Abstract
- 1. Introduction
- 1.1. Architecture
- 1.2. Deployment Tools and Methods
- 1.3. Supported Virtual Machine Operating Systems
- 1.4. Service Details
- 1.4.1. Dashboard Service Overview
- 1.4.2. Identity Service Overview
- 1.4.3. OpenStack Networking Service Overview
- 1.4.4. Block Storage Service Overview
- 1.4.5. Compute Service Overview
- 1.4.6. Image Service Overview
- 1.4.7. Object Storage Service Overview
- 1.4.8. Telemetry Service Overview
- 1.4.9. Orchestration Service Overview
- 2. Requirements
- 3. Installing the User Interface
- 4. Configuring the User Interface
- 5. Adding Hosts
- 6. Provisioning Red Hat Enterprise Linux OpenStack Platform
- 7. Monitoring Hosts
- A. Firewall Rules
- B. Configuring a Gateway
- C. Configuring the NTP Server
- D. Manual Procedures
- E. Revision History
Chapter 1. Introduction
- 1.1. Architecture
- 1.2. Deployment Tools and Methods
- 1.3. Supported Virtual Machine Operating Systems
- 1.4. Service Details
- 1.4.1. Dashboard Service Overview
- 1.4.2. Identity Service Overview
- 1.4.3. OpenStack Networking Service Overview
- 1.4.4. Block Storage Service Overview
- 1.4.5. Compute Service Overview
- 1.4.6. Image Service Overview
- 1.4.7. Object Storage Service Overview
- 1.4.8. Telemetry Service Overview
- 1.4.9. Orchestration Service Overview
- Fully distributed object storage
- Persistent block-level storage
- Virtual-machine provisioning engine and image storage
- Authentication and authorization mechanism
- Integrated networking
- Web browser-based GUI for both users and administration.
1.1. Architecture
keystone.conf.
Table 1.1. Services
| Service | Code Name | Description | |
|---|---|---|---|
| Dashboard | Horizon |
A web-based dashboard for managing OpenStack services.
|
| Identity | Keystone | A centralized Identity service that provides authentication and authorization for other services, and manages users, tenants, and roles. |
| OpenStack Networking | Neutron | A networking service that provides connectivity between the interfaces of other OpenStack services. |
| Block Storage | Cinder | A service that manages persistent block storage volumes for virtual machines. |
| Compute | Nova | A service that manages and provisions virtual machines running on hypervisor nodes. |
| Image | Glance | A registry service for storing resources such as virtual machine images and volume snapshots. |
| Object Storage | Swift | A service providing object storage which allows users to store and retrieve files (arbitrary data). |
|
Telemetry
| Ceilometer | A service providing measurements of cloud resources. |
|
Orchestration
| Heat | A service providing a template-based orchestration engine, which supports the automatic creation of resource stacks. |
glance-api and glance-registry Linux services, together with a MariaDB database, implement the Image service.
1.2. Deployment Tools and Methods
1.3. Supported Virtual Machine Operating Systems
1.4. Service Details
1.4.1. Dashboard Service Overview
Table 1.2. Dashboard service components
| Component | Description |
|---|---|
|
openstack-dashboard
|
A Django (Python) web application, provides access to the dashboard using any web browser.
|
|
An Apache HTTP server (
httpd service)
|
Hosts the application.
|
1.4.2. Identity Service Overview
adminURL, the URL for the administrative endpoint for the service. Only the Identity service might use a value here that is different from publicURL; all other services will use the same value.internalURL, the URL of an internal-facing endpoint for the service (typically the same as thepublicURL).publicURL, the URL of the public-facing endpoint for the service.region, in which the service is located. By default, if a region is not specified, the 'RegionOne' location is used.
- Users, which have associated information (such as a name and password). In addition to custom users, a user must be defined for each cataloged service (for example, the 'glance' user for the Image service).
- Tenants, which are generally the user's group, project, or organization.
- Roles, which determine a user's permissions.
Table 1.3. Identity Service components
| Component | Description |
|---|---|
|
keystone
|
Provides the administrative and public APIs.
|
|
Databases
|
For each of the internal services.
|
1.4.3. OpenStack Networking Service Overview
- Users can create networks, control traffic, and connect servers and devices to one or more networks.
- OpenStack offers flexible networking models, so that administrators can change the networking model to adapt to their volume and tenancy.
- IPs can be dedicated or floating; floating IPs allow dynamic traffic rerouting.
Table 1.4. OpenStack Networking Service components
| Component | Description |
|---|---|
|
neutron-server
|
A Python daemon, which manages user requests (and exposes the API). It is configured with a plug-in that implements the OpenStack Networking API operations using a specific set of networking mechanisms. A wide choice of plug-ins are also available. For example, the
openvswitch and linuxbridge plug-ins use native Linux networking mechanisms, while other plug-ins interface with external devices or SDN controllers.
|
|
neutron-l3-agent
|
An agent providing L3/NAT forwarding.
|
|
neutron-*-agent
|
A plug-in agent that runs on each node to perform local networking configuration for the node's virtual machines and networking services.
|
|
neutron-dhcp-agent
|
An agent providing DHCP services to tenant networks.
|
|
RabbitMQ server (
rabbitmq-server)
|
Provides the AMQP message queue. This server (also used by Block Storage) handles the OpenStack transaction management, including queuing, distribution, security, management, clustering, and federation. Messaging becomes especially important when an OpenStack deployment is scaled and its services are running on multiple machines.
|
|
Database
|
Provides persistent storage.
|
1.4.4. Block Storage Service Overview
- Create, list, and delete volumes.
- Create, list, and delete snapshots.
- Attach and detach volumes to running virtual machines.
Table 1.5. Block Storage Service components
| Component | Description |
|---|---|
|
openstack-cinder-volume
|
Carves out storage for virtual machines on demand. A number of drivers are included for interaction with storage providers.
|
|
openstack-cinder-api
|
Responds to and handles requests, and places them in the message queue.
|
|
openstack-cinder-backup
|
Provides the ability to back up a Block Storage volume to an external storage repository.
|
|
openstack-cinder-scheduler
|
Assigns tasks to the queue and determines the provisioning volume server.
|
|
Database
|
Provides state information.
|
|
RabbitMQ server (
rabbitmq-server)
|
Provides the AMQP message queue. This server (also used by Block Storage) handles the OpenStack transaction management, including queuing, distribution, security, management, clustering, and federation. Messaging becomes especially important when an OpenStack deployment is scaled and its services are running on multiple machines.
|
1.4.5. Compute Service Overview
Table 1.6. Ways to Segregate the Cloud
| Concept | Description |
|---|---|
|
Regions
|
Each service cataloged in the Identity service is identified by its region, which typically represents a geographical location, and its endpoint. In a cloud with multiple Compute deployments, regions allow for the discrete separation of services, and are a robust way to share some infrastructure between Compute installations, while allowing for a high degree of failure tolerance.
|
|
Cells
|
A cloud's Compute hosts can be partitioned into groups called cells (to handle large deployments or geographically separate installations). Cells are configured in a tree. The top-level cell ('API cell') runs the
nova-api service, but no nova-compute services. In contrast, each child cell runs all of the other typical nova-* services found in a regular installation, except for the nova-api service. Each cell has its own message queue and database service, and also runs nova-cells, which manages the communication between the API cell and its child cells.
This means that:
|
|
Host Aggregates and Availability Zones
|
A single Compute deployment can be partitioned into logical groups (for example, into multiple groups of hosts that share common resources like storage and network, or which have a special property such as trusted computing hardware).
If the user is:
Aggregates, or zones, can be used to:
|
Table 1.7. Compute Service components
| Component | Description |
|---|---|
|
openstack-nova-api
|
Handles requests and provides access to the Compute services (such as booting an instance).
|
|
openstack-nova-cert
|
Provides the certificate manager.
|
|
openstack-nova-compute
|
Creates and terminates virtual instances. Interacts with the Hypervisor to bring up new instances, and ensures that the state is maintained in the Compute database.
|
|
openstack-nova-conductor
|
Provides database-access support for Compute nodes (thereby reducing security risks).
|
|
openstack-nova-consoleauth
|
Handles console authentication.
|
|
openstack-nova-network
|
Handles Compute network traffic (both private and public access). Handles such tasks as assigning an IP address to a new virtual instance, and implementing security group rules.
|
|
openstack-nova-novncproxy
|
Provides a VNC proxy for browsers (enabling VNC consoles to access virtual machines).
|
|
openstack-nova-scheduler
|
Dispatches requests for new virtual machines to the correct node.
|
|
RabbitMQ server (
rabbitmq-server)
|
Provides the AMQP message queue. This server (also used by Block Storage) handles the OpenStack transaction management, including queuing, distribution, security, management, clustering, and federation. Messaging becomes especially important when an OpenStack deployment is scaled and its services are running on multiple machines.
|
|
libvirtd
|
The driver for the hypervisor. Enables the creation of virtual machines.
|
|
KVM Linux hypervisor
|
Creates virtual machines and enables their live migration from node to node.
|
|
Database
|
Provides build-time and run-time infrastructure state.
|
1.4.6. Image Service Overview
- raw (unstructured format)
- aki/ami/ari (Amazon kernel, ramdisk, or machine image)
- iso (archive format for optical discs; for example, CD)
- qcow2 (Qemu/KVM, supports Copy on Write)
- vhd (Hyper-V, common for virtual machine monitors from VMware, Xen, Microsoft, VirtualBox, and others)
- vdi (Qemu/VirtualBox)
- vmdk (VMware)
- bare (no metadata is included)
- ovf (OVF format)
- aki/ami/ari (Amazon kernel, ramdisk, or machine image)
Table 1.8. Image Service components
| Component | Description |
|---|---|
|
openstack-glance-api
|
Handles requests and image delivery (interacts with storage back-ends for retrieval and storage). Uses the registry to retrieve image information (the registry service is never, and should never be, accessed directly).
|
|
openstack-glance-registry
|
Manages all metadata associated with each image.
|
|
Database
|
Stores image metadata.
|
|
RabbitMQ server (
rabbitmq-server)
|
Provides the AMQP message queue. This server (also used by Block Storage) handles the OpenStack transaction management, including queuing, distribution, security, management, clustering, and federation. Messaging becomes especially important when an OpenStack deployment is scaled and its services are running on multiple machines.
|
1.4.7. Object Storage Service Overview
- Storage replicas, which are used to maintain the state of objects in the case of outage. A minimum of three replicas is recommended.
- Storage zones, which are used to host replicas. Zones ensure that each replica of a given object can be 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.
- Storage regions, which are essentially a group of zones sharing a location. Regions can be, for example, servers or server farms usually located in the same geographical area. Regions have a separate API endpoint per Object Storage service installation, which allows for a discrete separation of services.
Table 1.9. Object Storage Service components
| Component | Description |
|---|---|
|
openstack-swift-proxy
|
Exposes the public API, provides authentication, and is responsible for handling requests and routing them accordingly. Objects are streamed through the proxy server to the user (not spooled).
|
|
openstack-swift-object
|
Stores, retrieves, and deletes objects.
|
|
openstack-swift-account
|
Responsible for listings of containers, using the account database.
|
|
openstack-swift-container
|
Handles listings of objects (what objects are in a specific container), using the container database.
|
|
Ring files
|
Contain details of all the storage devices, and are used to deduce where a particular piece of data is stored (maps the names of stored entities to their physical location). One file is created for each object, account, and container server.
|
|
Account database
|
Stores account data.
|
|
Container database
|
Stores container data.
|
|
ext4 or XFS file system
|
Used for object storage.
|
|
Housekeeping processes
|
Replication, auditing, and updating processes.
|
1.4.8. Telemetry Service Overview
Table 1.10. Telemetry service components
| Component | Description |
|---|---|
|
ceilometer-agent-compute
|
An agent that runs on each Compute node to poll for resource utilization statistics.
|
|
ceilometer-agent-central
|
An agent that runs on a central management server to poll for utilization statistics about resources not tied to instances or Compute nodes.
|
|
ceilometer-collector
|
An agent that runs on one or more central management servers to monitor the message queues. Notification messages are processed and turned into Telemetry messages, and sent back out on to the message bus using the appropriate topic. Telemetry messages are written to the data store without modification.
|
|
ceilometer-notification
| An agent that pushes metrics to the collector service from various OpenStack services. |
|
MongoDB database
|
For collected usage data from collector agents. Only the collector agents and the API server have access to the database.
|
|
API Server
|
Runs on one or more central management servers to provide access to data in the database.
|
|
RabbitMQ server (
rabbitmq-server)
|
Provides the AMQP message queue. This server (also used by Block Storage) handles the OpenStack transaction management, including queuing, distribution, security, management, clustering, and federation. Messaging becomes especially important when an OpenStack deployment is scaled and its services are running on multiple machines.
|
- Each
nova-computenode must have aceilometer-computeagent deployed and running. - All nodes running the
ceilometer-apiservice must have firewall rules granting appropriate access. - The
ceilometer-central-agentcannot currently be horizontally scaled, so only a single instance of this service should be running at any given moment. - You can choose where to locate the additional Telemetry agents, as all intra-agent communication is either based on AMQP or REST calls to the
ceilometer-apiservice; as is the case for theceilometer-alarm-evaluatorservice.
1.4.9. Orchestration Service Overview
- A single template provides access to all underlying service APIs.
- Templates are modular (resource oriented).
- Templates can be recursively defined, and therefore reusable (nested stacks). This means that the cloud infrastructure can be defined and reused in a modular way.
- Resource implementation is pluggable, which allows for custom resources.
- Autoscaling functionality (automatically adding or removing resources depending upon usage).
- Basic high availability functionality.
Table 1.11. Orchestration service components
| Component | Description |
|---|---|
|
heat
|
A CLI tool that communicates with the heat-api to execute AWS CloudFormation APIs.
|
|
heat-api
|
An OpenStack-native REST API that processes API requests by sending them to the heat-engine over RPC.
|
|
heat-api-cfn
|
Provides an AWS-Query API that is compatible with AWS CloudFormation and processes API requests by sending them to the heat-engine over RPC.
|
|
heat-engine
|
Orchestrates the launching of templates and provide events back to the API consumer.
|
|
heat-api-cloudwatch
|
Provides monitoring (metrics collection) for the Orchestration service.
|
|
heat-cfntools
|
A package of helper scripts (for example, cfn-hup, which handles updates to metadata and executes custom hooks).
|
Note
heat-cfntools package is only installed on images that are launched by heat into Compute servers.
Chapter 2. Requirements
2.1. User Interface Environment Requirements
- A private network accessible by physical machines or virtual machines on which Red Hat Enterprise Linux OpenStack Platform components can be deployed. Services such as DHCP, DNS, and PXE must be disabled on this network because these services can interfere with the installer.
- A machine running Red Hat Enterprise Linux on which to set up the installer. This guide outlines how to install the user interface on this machine. For this machine, 6 GB of memory is recommended; a minimum of 4 GB memory is required.
Important
The machine on which you set up the installer must have a fully qualified domain name that satisfies the following requirements:- Matches the domain of the network to be provisioned.
- Does not conflict with any existing domains (to prevent resource conflicts).
Important
The installer can only run on Red Hat Enterprise Linux 6.6. To deploy Red Hat Enterprise Linux OpenStack Platform 5.0 on Red Hat Enterprise Linux 7.2 using the installer, you must first install the user interface for the installer on a Red Hat Enterprise Linux 6.6 system. From that system, you can then use the tool to deploy Red Hat Enterprise Linux OpenStack Platform 5.0 on Red Hat Enterprise Linux 7.2. - A machine that is a member of the private network and that also has access to external networks that can act as a router or gateway. The machine on which the user interface is installed can perform this function if required; see Appendix B, Configuring a Gateway for information on how to configure this machine to act as a gateway.
- The details of a Customer Portal account for subscribing the machine on which to install the user interface and for subscribing all hosts in your RHEL OpenStack Platform environment, including the user name, password, the ID of pools to attach, the names of channels to enable, and the details of a HTTP proxy, if any.
2.2. User Interface Client Requirements
- Level 1: Fully supported, preferred browsers for ideal experience.
- Level 2: Mostly supported. The user interface functions, but some design elements may not align correctly, the layout and user interface controls may not align correctly, and performance may be degraded.
- Level 3: Design elements may not align correctly.
- Level 4: Unsupported.
Table 2.1. Supported Browsers
| Browser | Version | Support Level |
|---|---|---|
| Firefox | 2.6 | L3 |
| Firefox | 17, 18, 19, 20 | L4 |
| Firefox | 21 | L2 |
| Firefox | 22, 23, 24 | L1 |
| Firefox | Latest | L1 |
| Chrome | 19, 20 | L4 |
| Chrome | 21, 27 | L2 |
| Chrome | Latest | L1 |
| Internet Explorer | 7, 8 | L4 |
| Internet Explorer | 9, 10, 11 | L2 |
| Safari | All | L4 |
2.3. Host Requirements
2.3.1. Controller Node Requirements
- Processor
- 64-bit x86 processor with support for the Intel 64 or AMD64 CPU extensions, and the AMD-V or Intel VT hardware virtualization extensions enabled.
- Memory
- A minimum of 2 GB of RAM is recommended.
- Disk Space
- A minimum of 50 GB of available disk space is recommended.Add additional disk space to this requirement based on the amount of space that you intend to make available to virtual machine instances. This figure varies based on both the size of each disk image you intend to create and whether you intend to share one or more disk images between multiple instances.1 TB of disk space is recommended for a realistic environment capable of hosting multiple instances of varying sizes.
- Network Interface Cards
- 2 x 1 Gbps Network Interface Cards.
2.3.2. Compute Node Requirements
- Processor
- 64-bit x86 processor with support for the Intel 64 or AMD64 CPU extensions, and the AMD-V or Intel VT hardware virtualization extensions enabled.
- Memory
- A minimum of 2 GB of RAM is recommended.Add additional RAM to this requirement based on the amount of memory that you intend to make available to virtual machine instances.
- Disk Space
- A minimum of 50 GB of available disk space is recommended.Add additional disk space to this requirement based on the amount of space that you intend to make available to virtual machine instances. This figure varies based on both the size of each disk image you intend to create and whether you intend to share one or more disk images between multiple instances.1 TB of disk space is recommended for a realistic environment capable of hosting multiple instances of varying sizes.
- Network Interface Cards
- 2 x 1 Gbps Network Interface Cards.
2.3.3. Network Node Requirements
- Processor
- No specific CPU requirements are imposed by the networking services.
- Memory
- A minimum of 2 GB of RAM is recommended.
- Disk Space
- A minimum of 10 GB of available disk space is recommended.No additional disk space is required by the networking services other than that required to install the packages themselves. However, some disk space must be available to store log files and temporary files.
- Network Interface Cards
- 2 x 1 Gbps Network Interface Cards.
2.3.4. Block Storage Node Requirements
openstack-cinder-volume) and provide volumes for use by virtual machine instances or other cloud users. The block storage API (openstack-cinder-api) and scheduling services (openstack-cinder-scheduler) can run on the same nodes as the volume service, or on separate nodes. In either case, the primary hardware requirement of the block storage nodes is that there is enough block storage available to serve the needs of the environment.
- The number of volumes that will be created in the environment.
- The average size of the volumes that will be created in the environment.
- Whether or not the storage back end will be configured to support redundancy.
- Whether or not the storage back end will be configured to create sparse volumes by default.
VOLUMES * SIZE * REDUNDANCY * UTILIZATION = TOTAL
- Replace VOLUMES with the number of volumes that are expected to exist in the environment at any one time.
- Replace SIZE with the expected average size of the volumes (in gigabytes) that will exist in the environment at any one time.
- Replace REDUNDANCY with the expected number of redundant copies of each volume that the back end storage will be configured to store. Use
1, or skip this multiplication operation if no redundancy is required. - Replace UTILIZATION with the expected percentage of each volume that will actually be used. Use
1, indicating 100%, if the use of sparse volumes will not be enabled.
Chapter 3. Installing the User Interface
Warning
Important
3.1. Subscribing to the Required Channels Using Subscription Manager
Procedure 3.1. Subscribing to the Required Channels Using Subscription Manager
- Register your system with the Customer Delivery Network, entering your Customer Portal user name and password when prompted:
#subscription-manager register - Find entitlement pools containing the channels required to install the Red Hat Enterprise Linux OpenStack Platform Installer.
#subscription-manager list --available | grep -A8 "Red Hat Enterprise Linux Server"#subscription-manager list --available | grep -A8 "Red Hat Enterprise Linux OpenStack Platform" - Use the pool identifiers located in the previous step to attach the
Red Hat Enterprise Linux 6 ServerandRed Hat Enterprise Linux OpenStack Platformentitlements:#subscription-manager attach --pool=pool_id - Enable the required channels:
#subscription-manager repos --enable=rhel-6-server-rpms#subscription-manager repos --enable=rhel-6-server-openstack-foreman-rpms#subscription-manager repos --enable=rhel-server-rhscl-6-rpms
3.2. Preparing an Installation Medium
3.2.1. Preparing an Installation Medium using a Web Server
Procedure 3.2. Preparing an Installation Medium
- Go to https://access.redhat.com, and log in to the Red Hat Customer Portal using your customer account details.
- Click in the menu bar.
- Click Red Hat Enterprise Linux to access the product download page.
- Click
RHEL 7.2 Binary DVD. - Install the Apache web server on the machine on which to host the installation medium:
# yum install httpd
- Start the
httpdservice, and ensure it starts on boot:- On Red Hat Enterprise Linux 6:
# service httpd start # chkconfig httpd on
- On Red Hat Enterprise Linux 7:
# systemctl start httpd.service
- In the root web server directory, create a directory in which to store the files for the installation medium:
# mkdir /var/www/html/[directory_name]
- Create a temporary directory into which to mount the ISO file:
# mkdir /RHEL7
- Mount the ISO file in the temporary directory:
# mount -t iso9660 -o loop rhel-server-7.2-x86_64-dvd.iso /RHEL7
- Copy the contents of the temporary directory to the directory in which to store the files for the installation medium:
# cp -dpR /RHEL7/* /var/www/html/[directory_name]
- Unmount the ISO file:
# umount /RHEL7
- Remove the temporary directory in which you mounted the ISO file:
# rmdir /RHEL7
3.2.2. Preparing an Installation Medium using NFS
Procedure 3.3. Preparing an Installation Medium using NFS
- Go to https://access.redhat.com, and log in to the Red Hat Customer Portal using your customer account details.
- Click in the menu bar.
- Click Red Hat Enterprise Linux to access the product download page.
- Click
RHEL 7.2 Binary DVD. - Install the nfs-utils package:
# yum install nfs-utils
- Create a directory to host the installation medium:
# mkdir /[directory_name]
- Add the newly created directory to the
/etc/exportsfile:/[directory_name] *(rw)
- Export the directory:
# exportfs -r
- Start the
nfsandrpcbindservices, and ensure they start on boot:- On Red Hat Enterprise Linux 6:
# service nfs start # service rpcbind start # chkconfig nfs on # chkconfig rpcbind on
- On Red Hat Enterprise Linux 7:
# systemctl start nfs.service # systemctl start rpcbind.service # systemctl enable nfs.service # systemctl enable rpcbind.service
- Create a temporary directory into which to mount the ISO file:
# mkdir /RHEL7
- Mount the ISO file in the temporary directory:
# mount -t iso9660 -o loop rhel-server-7.2-x86_64-dvd.iso /RHEL7
- Copy the contents of the temporary directory to the directory in which to store the files for the installation medium:
# cp -dpR /RHEL7/* /[directory_name]
- Unmount the ISO file:
# umount /RHEL7
- Remove the temporary directory in which you mounted the ISO file:
# rmdir /RHEL7
3.3. Installing the User Interface
rhel-osp-installer command to install the RHEL OpenStack Platform user interface and configure the core parameters that the installer uses to provision RHEL OpenStack Platform 5.0. See Section 3.4, “Options for Installing the User Interface” for a full list of the options available during the installation process.
Note
rhel-osp-installer command automatically configures the required SELinux permissions and adds the required firewall rules to iptables while preserving any existing firewall rules. See Appendix A, Firewall Rules for the list of firewall rules that the command configures.
Procedure 3.4. Installing the Red Hat Enterprise Linux OpenStack Platform Installer User Interface
- Install the rhel-osp-installer package:
#yum install rhel-osp-installer - Start the installation:
#rhel-osp-installer - Enter the number for the network interface that the installer will use to provision RHEL OpenStack Platform, and press Enter:
Please select NIC on which you want Foreman provisioning enabled: 1. eth1 2. eth0 ?
- Configure networking options:
- Enter the number for the configuration option to change, and press Enter.
- Enter a new value, and press Enter.
- When you have specified the preferred value for each configuration option, enter
1, and press Enter.
Networking setup: Network interface: 'eth1' IP address: 'XX.XX.XX.XX' Network mask: 'XX.XX.XX.XX' Network address: 'XX.XX.XX.XX' Host Gateway: 'XX.XX.XX.XX' DHCP range start: 'XX.XX.XX.XX' DHCP range end: 'XX.XX.XX.XX' DHCP Gateway: 'XX.XX.XX.XX' DNS forwarder: 'XX.XX.XX.XX' Domain: 'mydomain.example.com' Foreman URL: 'https://host.mydomain.example.com' NTP sync host: '0.rhel.pool.ntp.org' Timezone: 'America/New_York' Configure networking on this machine: ✓ Configure firewall on this machine: ✓ The installer can configure the networking and firewall rules on this machine with the above configuration. Default values are populated from the this machine's existing networking configuration. If you DO NOT want to configure networking please set 'Configure networking on this machine' to No before proceeding. Do this by selecting option 'Do not configure networking' from the list below. How would you like to proceed?: 1. Proceed with the above values 2. Change Network interface 3. Change IP address 4. Change Network mask 5. Change Network address 6. Change Host Gateway 7. Change DHCP range start 8. Change DHCP range end 9. Change DHCP Gateway 10. Change DNS forwarder 11. Change Domain 12. Change Foreman URL 13. Change NTP sync host 14. Change Timezone 15. Do not configure networking 16. Do not configure firewall 17. Cancel InstallationImportant
The name of the domain must match that of the fully qualified domain name of the machine on which the user interface is being installed.Important
By default, the address of the machine on which the user interface is being installed is specified as the DHCP gateway, which is the gateway the installer configures on hosts it provisions. If you have not configured the machine on which the user interface is being installed to act as a gateway, you must edit this value and specify the address of a machine that can perform this function. - Configure client authentication:
- Enter the number for the configuration option to change, and press Enter.
- Enter a new value, and press Enter.
- When you have specified either a SSH public key or a root password, enter
1, and press Enter.
Configure client authentication SSH public key: '' Root password: '*********' Please set a default root password for newly provisioned machines. If you choose not to set a password, it will be generated randomly. The password must be a minimum of 8 characters. You can also set a public ssh key which will be deployed to newly provisioned machines. How would you like to proceed?: 1. Proceed with the above values 2. Change SSH public key 3. Change Root password 4. Toggle Root password visibility - Specify the details of an installation medium:
- Enter
1, and press Enter. - Enter the address of a Red Hat Enterprise Linux Server 7.2 installation tree that the machine on which the user interface is being installed can access via a web server, and press Enter.
- Enter
2, and press Enter.
Now you should configure installation media which will be used for provisioning. Note that if you don't configure it properly, host provisioning won't work until you configure installation media manually. Enter RHEL repo path: 1. Set RHEL repo path (http or https URL): http:// 2. Proceed with configuration 3. Skip this step (provisioning won't work)
Important
If you choose not to configure installation media in this step, you will not be able to provision RHEL OpenStack Platform unless you manually configure an installation media entry in the user interface. - Specify the details of a Subscription Manager account:
- Enter the number for the configuration option to change, and press Enter.
- Enter a new value, and press Enter.
- When you have specified the preferred value for each configuration option, enter
9, and press Enter.
Enter your subscription manager credentials: 1. Subscription manager username: 2. Subscription manager password: 3. Comma separated repositories: rhel-7-server-openstack-5.0-rpms 4. Subscription manager pool (recommended): 5. Subscription manager proxy hostname: 6. Subscription manager proxy port: 7. Subscription manager proxy username: 8. Subscription manager proxy password: 9. Proceed with configuration 10. Skip this step (provisioning won't subscribe your machines)
Note
The value for the Subscription Manager pool must be in the format of a Subscription Manager entitlement pool ID. Moreover, you can only specify a single entitlement pool ID. If you leave the value for this configuration item blank, the installer attempts to auto-attach the required entitlements on systems it provisions.Important
If you choose not to specify your Subscription Manager account details in this step, you will not be able to provision RHEL OpenStack Platform unless you manually configure an operating system entry with the required details in the user interface.
3.4. Options for Installing the User Interface
3.4.1. Networking Setup Options
Table 3.1. Networking Setup Options
| Option | Description | ||
|---|---|---|---|
Network interface | The network interface on which the provisioning network is to be configured. The default values of other networking options, such as the IP address and Network address, are automatically specified based on the network interface you select. | ||
IP Address | The IP address of the machine where the user interface is being installed. | ||
Network mask | The network mask of the machine where the user interface is being installed. This value is also used to populate the network mask of the default subnet that the installer configures to act as the provisioning network. | ||
Network address | The network address of the default subnet that the installer configures to act as the provisioning network. This address must be in CIDR format. For example, XX.XX.XX.0/24. | ||
Host gateway | The address of a machine that can act as a gateway for the machine where the user interface is being installed. | ||
DHCP range start | The first address in the range of IP addresses that the installer can assign to machines on the provisioning network. This value is also used to populate the DHCP range start of the default subnet that the installer configures to act as the provisioning network. | ||
DHCP range end | The last address in the range of IP addresses that the installer can assign to machines on the provisioning network. This value is also used to populate the DHCP range end of the default subnet that the installer configures to act as the provisioning network. | ||
DHCP Gateway | The address of a machine that can act as a gateway for machines that the installer provisions. By default, the address of the machine where the user interface is being installed is specified as the DHCP gateway. If you have not configured the machine on which the user interface is being installed to act as a gateway, you must edit this value and specify the address of a machine that can perform this function. | ||
DNS forwarder | The address of a machine that can resolve IP addresses and host names. This value is also used to populate the primary DNS of the default subnet that the installer configures to act as the provisioning network. | ||
Domain | The name of the domain that the installer provides. The name of the domain must match that of the fully qualified domain name of the machine where the user interface is being installed. | ||
Foreman URL | The address for accessing the user interface. By default, this value is set to the fully qualified domain name of the machine where the user interface is being installed. | ||
NTP sync host | The address of an NTP server that the installer can use to synchronize the time on machines that it provisions. | ||
Timezone | The timezone that the installer applies to machines that it provisions. Timezones must be in the format of an IANA time zone identifier such as America/New_York or Asia/Tokyo. |
3.4.2. Client Authentication Options
Table 3.2. Client Authentication Options
| Option | Description | ||
|---|---|---|---|
SSH public key | A public SSH key that is copied to machines that the installer provisions. | ||
Root password | The password for the root user on machines the installer provisions. The password must be at least eight characters in length. If you do not manually specify a password, a random password is generated. |
3.4.3. Installation Media Options
Table 3.3. Installation Media Options
| Option | Description | ||
|---|---|---|---|
Set RHEL repo path (http or https URL) | The address of a Red Hat Enterprise Linux 7.2 installation tree. The path must end in the directory that contains directories such as isolinux, LiveOS, and repodata. This option is used to populate the default installation media entry that the installer uses to install the base operating system on machines that it provisions. |
3.4.4. Subscription Manager Options
Table 3.4. Subscription Manager Options
| Option | Description | ||
|---|---|---|---|
Subscription manager username | The username of a Customer Portal account that can be used to register machines that the installer provisions with the Content Delivery Network. | ||
Subscription manager password | A password that can be used to authenticate the above account. | ||
Comma separated repositories | A comma-separated list of repositories to enable on machines that the installer provisions. By default, the rhel-7-server-openstack-5.0-rpms channel, which provides the packages required to install Red Hat Enterprise Linux OpenStack Platform components, is provided. | ||
Subscription manager pool (recommended) | The ID of an entitlement pool to attach to machines that the installer provisions. Only a single entitlement pool ID can be specified, and if no entitlement pool ID is specified, the installer attempts to auto-attach the required entitlement pool. | ||
Subscription manager proxy hostname | The host name of a machine that can be used as a Subscription Manager proxy. | ||
Subscription manager proxy port | The port by which to connect with the Subscription Manager proxy. | ||
Subscription manager proxy username | A username by which to connect with the Subscription Manager proxy. | ||
Subscription manager proxy password | The password by which the authenticate the above username. |
Chapter 4. Configuring the User Interface
4.1. Logging in to the User Interface
Note
admin and the password randomly generated during the installation process. If you do not have a copy of this password, you can retrieve it by running the following command:
#grep admin_password /etc/foreman/rhel-osp-installer.answers.yaml
Procedure 4.1. Logging in to the User Interface
- In a web browser, navigate to the URL provided on completing installation of the user interface. By default, this URL comprises the fully qualified domain name of the machine on which the user interface is installed. For example,
https://myhost.example.com/. - Enter your username in the Username text field, and your password in the Password text field.
- Click the button.
4.2. Changing a Password
4.3. Installation Media
Note
Note
rhel-osp-installer command prompts you to specify the location of an installation medium during the installation process, and creates a default installation media entry based on this location. If you skipped this step when you installed the user interface, you must manually edit the RedHat mirror installation media entry and specify the location of a Red Hat Enterprise Linux 7 installation medium before you can provision RHEL OpenStack Platform.
4.3.1. Creating an Installation Media Entry
Procedure 4.3. Creating an Installation Media Entry
- From the title bar in the main screen of the user interface, click → .
- Click .
- In the Name text field, enter a name to represent the installation media entry in the user interface.
- In the Path text field, enter the path of a URL or an NFS share containing the installation tree. The following variables can be used in the path to represent multiple different system architectures and versions:
$arch- The system architecture, for example
x86_64. $version- The operating system version, for example
7.2. $major- The operating system major version, for example
7. $minor- The operating system minor version, for example
0.
- Select Red Hat from the Operating system family list.
- Click .
4.3.2. Specifying the Installation Media Entry for Provisioning
Procedure 4.4. Specifying the Installation Media Entry for Provisioning
- From the title bar in the main screen of the user interface, click → .
- Click the
base_RedHat_7host group. - Click the Operating System tab.
- Select an installation media entry from the Media list.
- Click .
4.3.3. Removing an Installation Media Entry
Procedure 4.5. Removing an Installation Media Entry
- From the title bar in the main screen of the user interface, click → to open the Installation Media page.
- Click the button that corresponds to the installation media entry to delete.
- Click when prompted.
Note
4.4. Operating Systems
Note
rhel-osp-installer command creates operating system entries for Red Hat Enterprise Linux 6.6 and Red Hat Enterprise Linux 7.2 that contain the details of the subscription manager account you entered during the installation process. These operating system entries can be edited as necessary.
4.4.1. Creating an Operating System Entry
Procedure 4.6. Creating an Operating System Entry
- Click → .
- Click .
- Configure general operating system details:
- In the Name text field, enter a name to represent the operating system entry in the Red Hat Enterprise Linux OpenStack Platform Installer.
- In the Major version, enter the number corresponding to the major version of the operating system.
- In the Minor version, enter the number corresponding to the minor version of the operating system.
- In the Description text field, enter a description to represent the operating system entry in the Red Hat Enterprise Linux OpenStack Platform Installer.
- From the OS Family drop-down menu, select the operating system family to which the operating system belongs.
- In the Architectures section, select the check boxes for the architectures that the operating system entry can provision.
- Configure the partition tables that the operating system entry can access:
- Click the Partition table tab.
- In the All items list, click the name of a partition table entry to move that partition table entry to the Selected items list.
- Configure the installation media that the operating system entry can access:
- Click the Installation media tab.
- In the All items list, click the name of an installation media entry to move that installation media entry to the Selected items list.
- Click .
4.4.2. Updating the Values of Operating System Entry Parameters
Note
Procedure 4.7. Updating the Values of Operating System Entry Parameters
- Click → .
- Click
RedHat 7.2to open the details page for the Red Hat Enterprise Linux 7.2 operating system entry. - Click the Parameters tab.
- Update the values of the parameters using the text fields for each parameter.
- Click .
4.4.3. Common Operating System Entry Parameters
Table 4.1. Common Operating System Entry Parameters
| Parameter | Description | ||
|---|---|---|---|
ntp-server | The address of an NTP server with which to synchronize the system clock. | ||
subscription_manager | Whether or not to use Subscription Manager. Accepted values are true or false. | ||
subscription_manager_repos | A comma-separated list of repositories to enable. The repository required to provision RHEL OpenStack Platform on Red Hat Enterprise Linux 7.2 is rhel-7-server-openstack-5.0-rpms. | ||
subscription_manager_pool | The ID of an entitlement pool to attach. You can only specify the ID of a single entitlement pool. This value is optional, but recommended; if you do not specify an entitlement pool ID, the installer attempts to auto-attach the required entitlements to hosts it provisions. | ||
subscription_manager_username | The username of a Customer Portal account by which to register the host with the Customer Delivery Network. | ||
subscription_manager_password | The password of a Customer Portal account by which to authenticate the above username. | ||
http-proxy | The IP address or fully qualified domain name of a HTTP proxy for Subscription Manager. | ||
http-proxy-port | The port by which to connect to the HTTP proxy for Subscription Manager. | ||
http-proxy-user | The name of the user by which to authenticate with the HTTP proxy for Subscription Manager. | ||
http-proxy-password | The password by which to authenticate with the HTTP proxy for Subscription Manager. | ||
time-zone | The time zone to apply to the host. Time zones must be in the format of an IANA time zone identifier such as America/New_York or Asia/Tokyo. |
4.4.4. Removing an Operating System Entry
Procedure 4.8. Removing an Operating System Entry
- Click → .
- Click the button for the operating system entry to delete.
- Click when prompted.
4.5. Provisioning Templates
Note
4.5.1. Creating a Provisioning Template
Procedure 4.9. Creating a Provisioning Template
- From the title bar in the main screen of the user interface, click → .
- Click .
- Configure general provisioning template details:
- Enter a name for the provisioning template in the Name field.
- Enter the body of the provisioning template in the Template editor text area.
- Enter a comment describing the creation of the provisioning template in the Audit Comment field.
- Configure the provisioning template type:
- Click the Type tab.
- Select Snippet to designate the provisioning template as a snippet. A snippet is not a standalone provisioning template, but a part of a provisioning template that can be inserted into other provisioning templates.
- If you did not select the Snippet check box, select the type of the provisioning template from the Type list:
- PXELinux: A PXELinux template.
- PXEGrub: A PXEGrub template.
- iPXE: An iPXE template.
- Provision: The main provisioning template, such as a kickstart file for Red Hat Enterprise Linux systems.
- finish: A post-installation script such as that specified in a kickstart file for Red Hat Enterprise Linux systems.
- script: A generic script that can be run during the provisioning process, such as that specified in a kickstart file for Red Hat Enterprise Linux systems.
- user_data: A
user_datablock. - ZTP: A zero touch provisioning template.
- Configure the provisioning template associations:
- Click the Associations tab.
- From the All items list in the Applicable Operating Systems section, click the name of an operating system entry to move that operating system entry to the Selected items list and make the provisioning template available to that operating system entry.
- Optionally, click and select a host group from the Host Group list or an environment from the Environment list to make the provisioning template available to the specified combination of host groups and environments.
- Click Submit.
4.5.2. Locking a Provisioning Template
Procedure 4.10. Locking a Provisioning Template
- From the title bar in the main screen of the user interface, click → .
- Click the disclosure arrow next to the button for the provisioning template.
- Click .
- Click when prompted.
4.5.3. Removing a Provisioning Template
Procedure 4.11. Removing a Provisioning Template
- From the title bar in the main screen of the user interface, click → .
- If the provisioning template is locked, you must first unlock it:
- Click the disclosure arrow next to the button for the provisioning template.
- Click and click when prompted.
- Click the disclosure arrow next to the button.
- Click and click when prompted.
4.6. Partition Tables
Note
Kickstart default. This partition table entry uses only the first disk available to the machine being provisioned; advanced configuration involving multiple disks must be manually configured. You can edit this partition table entry to configure the preferred partitioning scheme, or create a new partition table entry and specify that entry in the RedHat 7.2 operating system entry.
4.6.1. Creating a Partition Table Entry
Procedure 4.12. Creating a Partition Table Entry
- Click → .
- Click .
- In the Name text field, enter a name to represent the partition table in the user interface.
- In the Layout text area, enter the layout for the disk partition:
Note
The format of the layout must match that for the intended operating system to which the partition table is applied. For Red Hat Enterprise Linux 6.6 and Red Hat Enterprise Linux 7.2, the layout must match that of a kickstart file. - From the Os family drop-down menu, select the operating system family to which the partition table applies.
- Click
4.6.2. Removing a Partition Table Entry
Procedure 4.13. Removing a Partition Table Entry
- Click → .
- Click the button for the partition table entry to delete.
- Click when prompted.
4.7. Subnets
Note
4.7.1. Creating a Subnet
Procedure 4.14. Creating a Subnet
- From the title bar in the main screen of the user interface, click → .
- Click .
- Configure general subnet details:
- Enter a name for the subnet in the Name field.
- Enter the network address of the subnet in the Network address field.
- Enter the network mask for the subnet in the Network mask field.
- Enter the address of a gateway in the Gateway address field.
- Enter the address of the primary DNS server in the Primary DNS server field.
- Enter the address of the secondary DNS server, if any, in the Secondary DNS server field.
- Select the IP address management source from the IPAM list. If the subnet contains a DHCP server, select DHCP. If no DHCP capability exists on the subnet, select Internal DB and the Installer manages the IP address assignment and records IP addresses in its internal database. Select None for no IPAM management.
- Optionally, enter the start of the IP address range that the installer can auto-suggest for hosts in the Start of IP range field.
- Optionally, enter the end of the IP address range that the installer can auto-suggest for hosts in the End of IP range field.
- Optionally, enter the ID of a VLAN for the subnet.
- Select the default boot mode for interfaces assigned to the subnet from the Boot mode list. This sets the boot protocol for client network interfaces. Select DHCP to use the DHCP protocol or Static to manually assign IP address either manually through the host's network interface settings or using the Installer's IPAM Internal Database option.
- Configure domain membership:
- Click the Domains tab.
- Select the check box for all domains of which the subnet is a member.
- Click the Capsules tab to view the capsule settings. A capsule acts as a proxy for certain Installer services, such as DHCP, TFTP, and DNS.The Capsule settings are only required for the default subnet. This is because the Installer uses this subnet for host provisioning and deployment of Red Hat OpenStack Platform services. Any new subnets added to the Installer do not require Capsule settings.
- Click .
4.8. Users
4.8.1. Adding a User
Procedure 4.16. Adding a User
- Click → .
- Click the button to open the new user window.
- In the Username text field, enter the user name by which the user logs in to the user interface.
- In the First name and Surname text fields, enter the real first name and surname of the user.
- In the Email address text field, enter an email address by which the user can be contacted.
- From the Language drop-down menu, select the language by which the user interface is displayed to the user.
- Set a password for the user:
- From the Authorized by drop-down menu, select the directory by which the user will be authenticated.
- Enter an initial password for the user in the Password text field and again in the Verify text field.
- Click .
4.9. User Groups
4.9.1. Adding a User Group
Procedure 4.18. Adding a User Group
- Click → .
- Click the button.
- In the Name text field, enter a name by which to identify the user group in the user interface.
- From the list of check boxes in the User Groups section, select the check boxes to include the corresponding user groups in the new user group.
- From the list of check boxes in the Users section, select the check boxes to include the corresponding users in the new user group.
- Click the Roles tab.
- Select the Admin check box to grant administrator privileges to the users in the user group.
- From the list of roles in the All items list, click the name of a role to apply that role to the user group.
- Click .
4.9.2. Removing a User Group
Procedure 4.19. Removing a User Group
- Click → .
- Click the button for the user group to delete.
- Click when prompted.
4.10. Roles
4.10.1. Creating a Role
Procedure 4.20. Creating a Role
- Click → .
- Click .
- In the Name text field, enter a name by which to identify the role in the user interface.
- Click .
4.10.2. Adding Permissions to a Role
Procedure 4.21. Adding Permissions to a Role
- Click → .
- Click .
- From the Filters and permissions list for the role to edit, click to open the New Filter page.
- From the Resource type list, select the resource type to edit.
- From the list of permissions in the All items list, select the permissions to add to the role.
- Optionally, clear the Unlimited? check box and use the Search text field to specify a filter using search syntax.
- Click .
4.10.3. Removing Permissions from a Role
Procedure 4.22. Removing Permissions from a Role
- Click → .
- Click the Filters and permissions list for the role to edit to open the Filters page.
- From the Edit list for the permission to remove, click Delete.
- Click when prompted.
4.10.4. Removing a Role
Procedure 4.23. Removing a Role
- Click → .
- From the Filters and permissions list for the role to remove, click Delete.
- Click when prompted.
Chapter 5. Adding Hosts
5.1. Host Status Types
Table 5.1. Host Status Types
| Icon | Status | Description |
|---|---|---|
| Disabled | Alerts have been disabled for the host. The installer continues to collect reports from the host, but does not report the current status of the host. |
| Build | The host has been added to the user interface, but has not been provisioned. |
| Sync | The installer was unable to communicate with the host over the last report interval. |
| No Reports | No reports are available for the host. |
| Error | The installer has detected an error when attempting to collect reports from the host. |
| Active | Changes were applied to the host over the last report interval. |
| Pending | There are changes that are scheduled to be applied to the host. |
| OK | The host encountered no errors over the last report interval, no changes were applied to the host during that interval, and there are no pending changes. |
5.2. Adding Hosts
Note
/usr/share/foreman-discovery-image/ directory on the machine on which the user interface is installed. Access to the discovery image over the network is automatically configured when you install the user interface; no user input is required.
5.2.1. Adding a Host via Discovery
Procedure 5.1. Adding a Host via Discovery
- Start the host, and elect to start over the network from the boot options menu to start the host using the PXE service that the installer provides.
- Select
Foreman Discoveryfrom the PXE boot options menu. The host starts into the Foreman Discovery screen and is automatically registered in the user interface. - Log in to the user interface and confirm that the host has been registered:
- Click → .
- Click the name of the newly registered host to open the details page for the host, and review the details.
discovery environment, which is the default Puppet environment for discovered hosts in which no Puppet classes are defined. This environment acts as a holding area that identifies hosts that have not yet been provisioned.
5.3. The Host Overview Page
Note
The Details Bar
- Audits
- Displays a page containing audit entries for the current host, if any.
- Facts
- Displays the Facts page, and applies a filter so that only the facts for the current host are displayed. This button is only available after the installer has collected facts from the host.
- Reports
- Displays the Reports page, and applies a filter so that only the reports for the current host are displayed. This button is only available after the installer has collected reports from the host.
- YAML
- Displays a page containing details about the host in YAML format, such as its IP address, MAC address, and the name and values of parameters that have been applied to the host.
- Properties
- A list of general details about the host, such as its IP address, MAC address, and the operating system entry that has been applied to the host.
- Metrics
- A table displaying a summary of all events reported for the host.
- Templates
- A list of all provisioning templates currently accessible by the host. The provisioning templates include in this list are automatically configured in accordance with the operating system entry applied to the host.
Host Actions
- Edit
- Opens the host details page for the host and allows you to configure settings for the host. However, in principle, the installer configures all the details required for provisioning the host, and no manual configuration is required.
- Build
- Flags the host to be provisioned the next time it is restarted. After you click this button, the label changes to , which allows you to cancel the provisioning operation. The button reverts to after provisioning is complete. However, in principle, the installer manages all aspects of the provisioning process, and you do not need to manually provision hosts.
- Run puppet
- Executes a Puppet run on the host. This button is disabled by default, and must be manually enabled by setting the value of the
puppetrunoption totruein the Puppet tab of the Settings page accessed by clicking → . - Delete
- Deletes the host from the user interface.
Host Graphs
- Runtime
- This graph tracks two data points: Config Retrieval, and Runtime. The Config Retrieval data point represents the amount of time taken to collect information about the host during a given Puppet run, and the Runtime data point represents the amount of time required to execute the Puppet run. Both data points are measured in seconds.
- Resources
- This graph tracks the number of actions performed on the host during a Puppet run. The categories displayed in this graph are identical to those displayed in the Reports page, and are measured using the number of actions in each category.
Chapter 6. Provisioning Red Hat Enterprise Linux OpenStack Platform
6.1. Deployments
Compute N, represents additional compute nodes that can be added to the environment after it has been provisioned to enable horizontal scaling. The final server icon in the diagram represents a Ceph OSD node.
- The yellow network represents a public network that only the installer uses. This network allows the installer to communicate with external network resources such as the Content Delivery Network. It is configured manually on the host where the user interface is installed. Moreover, access to the dashboard from external networks can also be enabled by placing public API traffic on the same subnet as the provisioning network described below, or by optionally creating a dedicated subnet for this network traffic type and configuring external routing.
- The green network represents the provisioning network that the installer defines when you install the user interface. This network carries traffic between the installer and the hosts in the deployment. This is the network that the installer uses to boot hosts using PXE, and to set up and configure hosts when you provision a RHEL OpenStack Platform environment. While the installer defines this network when you install the user interface, you must also create a subnet to carry this network traffic when you create a deployment. Moreover, while this network traffic type is carried over a dedicated subnet in this deployment, this network traffic type can be shared with any of the network traffic types carried by the blue network outlined below. The subnet that carries this network traffic type must be assigned to every host in the deployment.
- The blue network represents a private network that carries network traffic between the nodes in a RHEL OpenStack Platform environment. This network carries management, cluster management, administrative API, storage, and storage clustering network traffic. The subnet that carries these network traffic types must be assigned to every host in the deployment.
- The red network represents a public network that carries network traffic between instances in the RHEL OpenStack Platform environment and external networks. This network provides external network connectivity to virtual machines. A dedicated subnet must be created to carry this type of network traffic. The subnet that carries this network traffic type is only assigned to controller nodes.
6.1.1. Creating a Deployment
Procedure 6.1. Creating a Deployment
- Click → .
- Configure deployment settings:
- Enter a name for the deployment in the Name field.
- Enter a description in the Description field.
- Select either Controller / Compute or High Availability Controllers / Compute in the High Availability section.
- Select either Neutron Networking or Nova Network in the Networking section.
- Select either RabbitMQ or Qpid as the message broker in the Messaging Provider section.
Note
As of Red Hat Enterprise Linux OpenStack Platform 5, RabbitMQ replaces QPid as the default (and recommended) message broker. - Ensure Red Hat Enterprise Linux OpenStack Platform 5 with RHEL 7 is selected in the Platform section.
- Select Generate random password for each service in the Service Password section to generate a random password for each service, or select Use single password for all services and enter a password in the Password and Verify fields to set the same password for all services.
- Optionally, enter a list of custom repositories in the Custom repos text area. Multiple custom repositories must be added on separate lines, and each custom repository must take the form of a base URL.
- Click .
- Configure network traffic:
- Drag and drop the available network traffic types into the section for a subnet.
- Create new subnets if you require a new subnet to which to assign a network traffic type:
- Click .
- Enter a name to represent the subnet in the user interface in the Name field.
- Select External DHCP or No existing DHCP from the DHCP server list.Setting DHCP server to External DHCP means an external DHCP server exists on the subnet and the Installer sets the boot mode of clients on this subnet to use DHCP.Setting DHCP server to No existing DHCP means no DHCP server exists on the subnet and the Installer assigns static IP addresses to clients on the subnet. These static IP addresses are recorded in the Installer's database, which gives the Installer a DHCP-like capability. If you select No Existing DHCP and the subnet is to carry the Public API network traffic type, you must enter the address of a machine that can act as a gateway in the Gateway field. If you select No existing DHCP, you can also specify the IP Range Start and the IP Range End.
- Enter the network address in the Network Address field. This address must be in CIDR notation. For example,
XX.XX.XX.0/24. - Optionally, enter a VLAN ID for the subnet in the VLAN field.
- Click .
- Click .
Note
By default, all network traffic types except External is assigned to the default subnet. Because the External network traffic type is required and cannot be assigned to the same subnet as other network traffic types, you must create a dedicated subnet for this network traffic type. You can then drag and drop network traffic types to subnets as required, or to the Available Network Traffic Types section to disable optional network traffic types. - In the Services Overview step, review the list of services to be provisioned, and click .
- Configure service options:
Neutron
Options for this service are only available if you selected Neutron Networking in the Deployment Settings step.- Select a Tenant Network Type.
- Select a Core Plugin Type.
Nova
Options for this service are only available if you selected Nova Network in the Deployment Settings step.- Select a Tenant Network Type.
- Enter a Floating IP range for external network.
- Enter a Fixed IP range for tenant networks.
Glance
- Select a driver backend from the Choose Driver Backend radio boxes.
Cinder
- Select one or more driver backends from the Choose Driver Backend check boxes.
- Click .
6.1.2. New Deployment Settings
6.1.2.1. Network Configuration Settings
Table 6.1. Network Configuration Settings
| Network Traffic Type | Description | ||
|---|---|---|---|
| Provisioning/PXE | Communication with the installer. For example, to provision hosts and to allow hosts to boot over the network using the PXE service that the installer provides. | ||
| Management | Private communication amongst services. | ||
| External | Communication between instances in the RHEL OpenStack Platform environment and external network resources. This network traffic type cannot be placed on the same subnet as other network traffic types. | ||
| Cluster Management | Pacemaker cluster management communication. | ||
| Admin API | Administrative communication amongst services. | ||
| Public API | Access to the REST API and the Horizon dashboard. | ||
| Tenant | Tenant network communication for instances in the RHEL OpenStack Platform environment. | ||
| Storage | Storage-related communication. This network traffic type is optional. | ||
| Storage Clustering | Storage-related communication for replication and data checks in Ceph clusters. This network traffic type is optional. |
6.1.2.2. Services Configuration Settings
Table 6.2. Services Configuration Settings
| Service | Option | Description | |
|---|---|---|---|
| Neutron | Tenant Network Type | The type of network used for tenant networks. You can choose from the following options:
| |
| Core Plugin Type |
The core network plugin. You can choose from the following options:
ML2 Core Plugin
The modular layer 2 plugin. If you select this plugin, you can select the following ML2 mechanism drivers:
N1KV Core Plugin
The Cisco 1000v plugin. If you select this plugin, you must also specify the details of a virtual supervisor module:
| ||
| Nova | Tenant Network Type |
| |
| Floating IP range for external network | A range of IP addresses to be used for external networks. Ranges must be entered using CIDR notation. For example, XX.XX.XX.0/24. | ||
| Fixed IP range for tenant networks | A range of IP addresses to be used for tenant networks. Ranges must be entered using CIDR notation. For example, XX.XX.XX.0/24. | ||
| Glance | Choose Driver Backend | The driver to use for back-end storage of images. You can choose from the following options:
| |
| Cinder | Choose Driver Backend | The volume driver to use for back-end storage. You can choose from the following options:
|
6.1.3. Editing a Deployment
Important
Procedure 6.2. Editing a Deployment
- Click → to open the OpenStack Deployments page.
- Click the name of a deployment to open the details page for that deployment.
- Click the name of the deployment to edit the name, and click when complete to make the change persistent.
- Click the description of the deployment to edit the description, and click when complete to make the change persistent.
- Optionally, click the button to open the setup wizard and configure further options such as the messaging broker and the password with which to authenticate services.
6.1.4. Removing a Deployment
Procedure 6.3. Removing a Deployment
- Click → .
- Click the button for the deployment to remove.
- Click when prompted.
6.2. Assigning Hosts to Deployment Roles
Without High Availability (Neutron)
- One controller node.
- One or more compute nodes.
- One Neutron networking node.
Without High Availability (Nova)
- One controller node.
- One or more compute nodes.
With High Availability (Nova and Neutron)
- Three controller nodes.
- One or more compute nodes.
6.2.1. Assigning a Host to a Deployment Role
Procedure 6.4. Assigning Hosts to Deployment Roles
- Click → .
- Click the name of the deployment to which to assign hosts to open the details page for that deployment.
- In the Deployment Roles section, click for a deployment role to display the Free Hosts section for that deployment role:
- Controller
- Provides key services such as the MySQL database for storing data about your environment, Horizon, Keystone, and Glance.
- Compute
- A host that acts as a hypervisor, providing the processing capabilities required for running virtual machines in the environment. You can add more Compute nodes to your environment at any time by assigning additional hosts to this deployment role and repeating the provisioning process; the installer ignores all hosts that have already been provisioned and provisions only the new host.
- Neutron Networking
- Provides Neutron networking services. This deployment role is only available when you select Neutron networking as the networking back end for your deployment and have selected not to use high availability.
- Ceph Storage Node (OSD)
- A generic Red Hat Enterprise Linux 7.2 host that can be manually configured after deployment to act as a Ceph storage server node. This deployment role is optional.
- Generic RHEL 7
- A generic Red Hat Enterprise Linux 7.2 host that can be manually configured after deployment to provide services not defined by any of the pre-existing deployment roles. This deployment role is optional.
- Select the check box for a host in the Free Hosts section.
- Click to assign the host to the selected deployment role.
6.2.2. Unassigning a Host from a Deployment
Procedure 6.5. Unassigning Hosts from Deployment Roles
- Click → .
- Click the name of the deployment from which to unassign hosts to open the details page for that deployment.
- In the Deployment Roles section, click the assigned hosts (
) button for a deployment role to display the Assigned Hosts section for that deployment role.
- Select the check box for a host in the Assigned Hosts section.
- Click to unassign the host from the selected deployment role.
6.3. Configuring Host Networking
6.3.1. Configuring Networking on a Host
Procedure 6.6. Configuring Networking on a Host
- Click → .
- Click the name of a deployment to open the details page for that deployment.
- Click the Hosts tab.
- Click the Assigned sub-tab.
- Select the check box for a host and click Configure Networks.
- Drag and drop subnets between the sections for network interfaces to change the network traffic carried by those interfaces.
- Optionally, configure a bond between two network interfaces:
- Click the bonding button for a network interface and click the name of a network interface to bond the two network interfaces.
- Select the bonding mode from the Bonding Mode list.
- Click .
6.3.2. Bonding Modes
Table 6.3. Bonding Mode
| Bonding Mode | Description | ||
|---|---|---|---|
| balance-rr | The packets in all inbound and outbound network traffic handled by the bond is transmitted sequentially through each of the network interfaces in the bond. For example, if there are two network interfaces in the bond, the first packet is handled by the first network interface, the second packet is handled by the second network interface, and the third packet is handled by the first network interface. | ||
| active-backup | One of the network interfaces in the bond is designated as the active network interface, and the other network interface is designated as a backup. Inbound and outbound network traffic are both handled only by the active network interface. Network traffic is only handled by the backup network interface when the active network becomes unavailable and the backup network interface becomes the active network interface. | ||
| balance-xor | Network traffic is handled by the network interfaces in the bond in accordance with an XOR formula. With this bonding mode, network traffic from a given source MAC address is always handled by the same destination MAC address in the network interface. | ||
| broadcast | All inbound and outbound network traffic is passed through all network interfaces in the bond. | ||
| 802.3ad | All inbound and outbound network traffic is handled in accordance with aggregation groups that each have the same speed and duplex settings. | ||
| balanced-tlb | Inbound network traffic is handled by the current network interface. Outbound network traffic is distributed amongst the active network interfaces in the bond in accordance with the load on each network interface. | ||
| balance-alb | In addition to distributing outbound network traffic in a similar fashion to balance-tlb, inbound IPv4 network traffic is also distributed amongst the active network interfaces in the bond. |
6.4. Configuring Fencing
Note
Important
6.4.1. Configuring Fencing on High-Availability Nodes
Procedure 6.7. Configuring Fencing on High-Availability Nodes
- From the title bar in the main screen of the user interface, click → .
- Click the name of the host to configure.
- Click .
- Click the Fencing tab.
- If the message Fencing is disabled. To enable, first you need to add a BMC interface to the Host is displayed, you must manually configure the details of a baseboard management controller network interface controller attached to the host:
- Click the Network tab.
- Click .
- Select
BMCfrom the Type list. - Enter the MAC address for the network interface controller in the MAC address field.
- Click the Fencing tab.
- Select Enable Fencing.
- Select IPMI from the Type list.
- Enter the IP address of the fencing device in the IP Address field.
- Enter the name of the IPMI user on the fencing device in the Username field.
- Enter the password by which to authenticate the above user in the Password field.
- Select Expose Lanplus to use the
lanplusinterface. - If you selected the Expose Lanplus check box, enter any options in the Lanplus Options field.
- Click .
6.5. Deployment Configurations
Important
6.5.1. Viewing the Configuration of a Deployment
Procedure 6.8. Viewing the Configuration of a Deployment
- Click → .
- Click the name of a deployment.
- Click .
- Click the name of a service to view the parameters for that service.
- Click to return to the deployment details page when finished.
6.5.2. Editing Service Parameters
- Click → .
- Click the name of a deployment.
- Click .
- Click .
- Click the name of a service to view the parameters for that service.
- Enter a new value for the parameter in the text field for that parameter.
- Click
6.5.3. Importing a Deployment Configuration
Procedure 6.9. Importing a Deployment Configuration
- Click → .
- Click the name of a deployment to open the details page for that deployment.
- Click .
- Click to open the Import Config pop-up window.
- Click and search your local system for the configuration file to upload.
- Click .
Important
6.5.4. Exporting a Deployment Configuration
Procedure 6.10. Exporting a Deployment Configuration
- Click → .
- Click the name of a deployment.
- Click .
- Click from the list.
6.6. Provisioning Red Hat Enterprise Linux OpenStack Platform
6.6.1. Provisioning Red Hat Enterprise Linux OpenStack Platform
Procedure 6.11. Provisioning Red Hat Enterprise Linux OpenStack Platform
- Click → .
- Click the name of the deployment to provision.
- Click to open the deployment confirmation screen.
- Click .
production environment, which contains the Puppet classes required to provision RHEL OpenStack Platform. The hosts are provisioned in accordance with the role to which they are assigned in the deployment, and the progress of provisioning is displayed.
6.6.2. Retrieving Service Details
Procedure 6.12. Retrieving Service Details
- Click → .
- Click the name of a deployment you have provisioned.
- Review the details of the deployment.
- Optionally, click the button to display the All details window, which displays a list of the passwords for all services in your environment.
6.6.3. Logging In
- HTTPS
https://HOSTNAME/dashboard/
- HTTP
http://HOSTNAME/dashboard/
admin user. To begin using the OpenStack deployment, see the Administration User Guide and Cloud Administrator Guide.
6.6.4. Next Steps
Important
puppet service on the host.
- Administration User Guide
- Provides an overview of how to create and manage resources in a RHEL OpenStack Platform environment using the Horizon dashboard or client commands for administrative users.
- End User Guide
- Provides an overview of how to create and manage resources in a RHEL OpenStack Platform environment using the Horizon dashboard or client commands for end users.
- Cloud Administrator Guide
- Provides an overview of the software that administrators can use to manage and troubleshoot a RHEL OpenStack Platform environment.
- Configuration Reference Guide
- Provides a reference for administrative users for looking up configuration options. This guide contains lists of the configuration options available with RHEL OpenStack Platform and uses auto-generation to generate options and the descriptions from the code for each project.
Chapter 7. Monitoring Hosts
7.1. Dashboard
7.2. Reports
- Applied: The number of changes that were applied to resources on the host, such as files, directories, or user accounts.
- Restarted: The number of resources, such as services, that were restarted.
- Failed: The number of actions that were executed but did not complete successfully.
- Restart Failures: The number of resources, such as services, that were scheduled to restart but did not restart successfully.
- Skipped: The number of actions that were scheduled, but were skipped due to a problem scheduling the Puppet run.
- Pending: The number of actions that were scheduled to be applied, but had not yet been performed at the time the report was collected.
7.2.1. Changing the Report Interval
Procedure 7.1. Changing the Report Interval
- From the main title bar, click → .
- Click the Puppet tab.
- Click the edit icon next to the value of the puppet_interval setting.
- Enter a new report interval in minutes.
- Click .
7.2.2. Deleting Reports in a Batch
Procedure 7.2. Deleting Reports
- Log in to the machine on which the user interface is installed as the root user.
- Delete all reports more than [days] number of days old:
#foreman-rake reports:expire days=[days]
7.3. Facts
- Host: The host that the fact describes.
- Name: The name of the fact.
- Value: The value of the fact.
- Reported at: The time at which the fact was collected.
- Chart: A button that displays a pie chart representing the relative frequency of the value of the given fact across all hosts that the installer manages.
7.4. Tasks
- Action: The action being performed.
- State: The current state of the task.
- Result: The outcome of the task, if any.
- Started at: The time at which the task was initiated.
- User: The user in the user interface that initiated the task.
Appendix A. Firewall Rules
rhel-osp-installer command configures when you install the user interface. The installer uses these ports to communicate with and control other machines in the environment. This table is provided for your information; no further configuration is necessary beyond that provided by rhel-osp-installer.
Table A.1. Red Hat Enterprise Linux OpenStack Platform Installer Firewall Rules
| Ports | Protocols | Service | Purpose |
|---|---|---|---|
| 22 | TCP | SSH | Connecting to other machines on the private network that the installer defines. |
| 53 | TCP, UDP | DNS | Resolving the host names and addresses of machines on the private network that the installer defines. |
| 67 | TCP | DHCP | Assigning IP addresses to machines on the private network that the installer defines. |
| 69 | TCP | TFTP | Enabling the PXE booting of machines on the private network that the installer defines. |
| 80, 443 | TCP | HTTP, HTTPS | The Apache web server for hosting the user interface for the installer. |
| 8140 | TCP | Puppet | Communication between Puppet clients and the Puppet master. |
Appendix B. Configuring a Gateway
Procedure B.1. Configuring a Gateway
- Log in to the machine on which you will install the user interface as the root user.
- Edit
/etc/sysctl.confand change the value ofnet.ipv4.ip_forwardto1:net.ipv4.ip_forward = 1 - Load the new value:
#sysctl -p - Enable IP masquerading:
#iptables -t nat -A POSTROUTING -o [if_name] -j MASQUERADE#iptables -A FORWARD -s [XX.XX.XX.XX/XX] -j ACCEPT#iptables -A FORWARD -d [XX.XX.XX.XX/XX] -j ACCEPT#iptables -A FORWARD ! -s [XX.XX.XX.XX/XX] -j DROP- [if_name]: The name of the network interface to which to forward network traffic. You must specify the name of the network interface that will not be used for the private provisioning network.
- [XX.XX.XX.XX/XX]: The network address of the private provisioning network that the installer defines. You must specify this address using CIDR notation. For example,
XX.0.0.0/8,XX.XX.0.0/16, orXX.XX.XX.00/24.
- Save the changes to the firewall:
#service iptables save - Restart networking:
#service network restart
Appendix C. Configuring the NTP Server
Procedure C.1. Configuring the NTP Server
- Log into the user interface.
- Navigate to → .
- In Filter, type
ntpand click Search. - Click on ntp and navigate to →
- Check Override and enter the NTP server's hostname or IP address in the Default Value field.
- Click Submit.
- Navigate to → .
- For each Host Group:
- Click on the Host Group's name.
- Navigate to Puppet Classes.
- Navigate to the ntp Puppet class group and expand it.
- Select the ntp class. This class moves to the Included Classes list.
- Click Submit.
Appendix D. Manual Procedures
D.1. Configuring Fencing on High-Availability Nodes
Note
Important
Procedure D.1. Configuring Fencing on High-Availability Nodes
- Stop and disable the
puppetservice:#systemctl stop puppet.service#systemctl disable puppet.serviceNote
Disabling thepuppetservice prevents future changes from being applied to the controller nodes. To apply any changes, you must enable thepuppetservice and apply the changes. You must then disable thepuppetservice again and repeat the final step in this procedure to reactivate fencing. - Configure IPMI:
- Ensure the
ipmiservice is running:#systemctl start ipmi.service - Configure and activate an IPMI user with administrative privileges:
#ipmitool user set name 2 user_name#ipmitool user set password 2 password#ipmitool user priv 1 4#ipmitool user enable 2
- Create a fencing agent:
#pcs stonith create fence_agent_name fence_ipmilan login=user_name passwd=password ipaddr=ip_address pcmk_host_list="host_name"fence_agent_name: A human-readable name for the fencing agent.user_name: The name of the IPMI user on the fencing device.password: The password for the IPMI user on the fencing device.ip_address: The IP address of the fencing device.host_names: The host name of the node.
- Confirm that the fencing agent has been correctly created:
#pcs status - Enable fencing:
#pcs property set stonith-enabled=true
D.2. Adding a Host Manually
Note
Procedure D.2. Adding a Host Manually
- Click → .
- Configure host details:
- Enter a name to represent the host in the user interface in the Name field.
- Leave the Host Group list blank.
- Select Bare Metal from the Deploy on list.
- Select Discovery from the Environment list.
- Select the server to act as the Puppet CA for the host from the Puppet CA list.
- Select a server to act as the initial puppet server for the host from the Puppet Master list.
- Configure networking options:
- Click the Network tab.
- Select the domain to which the host is to belong from the Domain list.
- Leave the Realm list blank.
- Enter the MAC address of the host in the MAC address field.
- Select the subnet to which the host belongs from the Subnet list. The IP address field is automatically populated based on the subnet you select.
- Configure the Operating System
- Click the Operating System tab.
- Select the architecture of the host from the Architecture list.
- Select the operating system to install on the host from the Operating system list.
- Select the Build mode check box.
- Select the installation media entry by which to install the selected operating system from the Media list.
- Select the partitioning scheme to be applied to the host from the Partition table list.
- Enter a password for the
rootuser on the host in the Root password list.
- Click .
Appendix E. Revision History
| Revision History | ||||||||
|---|---|---|---|---|---|---|---|---|
| Revision 5.0.0-32 | Thu Mar 17 2016 | |||||||
| ||||||||
| Revision 5.0.0-31 | Tue Nov 17 2015 | |||||||
| ||||||||
| Revision 5.0.0-30 | Thu Apr 16 2015 | |||||||
| ||||||||
| Revision 5.0.0-29 | Wed Feb 11 2015 | |||||||
| ||||||||
| Revision 5.0.0-28 | Wed Feb 11 2015 | |||||||
| ||||||||
| Revision 5.0.0-27 | Mon Dec 15 2014 | |||||||
| ||||||||
| Revision 5.0.0-26 | Wed Nov 12 2014 | |||||||
| ||||||||
| Revision 5.0.0-25 | Tue Nov 11 2014 | |||||||
| ||||||||
| Revision 5.0.0-24 | Thu Nov 6 2014 | |||||||
| ||||||||
| Revision 5.0.0-23 | Thu Nov 6 2014 | |||||||
| ||||||||
| Revision 5.0.0-22 | Fri Oct 31 2014 | |||||||
| ||||||||
| Revision 5.0.0-21 | Mon Oct 27 2014 | |||||||
| ||||||||
| Revision 5.0.0-20 | Thu Oct 16 2014 | |||||||
| ||||||||
| Revision 5.0.0-19 | Thu Oct 9 2014 | |||||||
| ||||||||
| Revision 5.0.0-18 | Tue Oct 7 2014 | |||||||
| ||||||||
| Revision 5.0.0-17 | Tue Sep 30 2014 | |||||||
| ||||||||
| Revision 5.0.0-16 | Fri Sep 26 2014 | |||||||
| ||||||||
| Revision 5.0.0-15 | Mon Sep 22 2014 | |||||||
| ||||||||
| Revision 5.0.0-14 | Tue Sep 16 2014 | |||||||
| ||||||||
| Revision 5.0.0-13 | Tue Sep 16 2014 | |||||||
| ||||||||
| Revision 5.0.0-12 | Mon Aug 25 2014 | |||||||
| ||||||||
| Revision 5.0.0-11 | Mon Aug 25 2014 | |||||||
| ||||||||
| Revision 5.0.0-10 | Thu Aug 21 2014 | |||||||
| ||||||||
| Revision 5.0.0-9 | Thu Aug 21 2014 | |||||||
| ||||||||
| Revision 5.0.0-8 | Thu Aug 14 2014 | |||||||
| ||||||||
| Revision 5.0.0-7 | Fri Aug 8 2014 | |||||||
| ||||||||
| Revision 5.0.0-6 | Thu Aug 7 2014 | |||||||
| ||||||||
| Revision 5.0.0-5 | Wed Aug 6 2014 | |||||||
| ||||||||
| Revision 5.0.0-4 | Tue Jul 22 2014 | |||||||
| ||||||||
| Revision 5.0.0-3 | Fri Jul 11 2014 | |||||||
| ||||||||
| Revision 5.0.0-2 | Wed Jul 9 2014 | |||||||
| ||||||||
| Revision 5.0.0-1 | Thu Jun 26 2014 | |||||||
| ||||||||

















































