Red Hat OpenStack Administration I: Core Operations for Domain Operators

After completing this section, you should be able to create the requisite resources and launch a simple virtual machine instance.

Red Hat OpenStack Platform includes the OpenStackClient (OSC), designed to implement all the common, necessary functionality offered by the OpenStack services APIs. This Python-based client is generally equivalent to the CLI clients provided by the original OpenStack project client libraries, but with a distinct and consistent unified command structure. This simplifies operations within the Red Hat OpenStack Platform environment.

The OSC requires user authentication before allowing access to Red Hat OpenStack Platform services. For successful authentication, you need to specify at least a user name, password, project name, domain name, API version, and a public URL to the Identity API endpoint. You can provide the parameters as either environment variables or arguments to the openstack command.

Red Hat recommends using run control (rc) environment files, one for each user and project combination, to set a user's authentication parameters for a project. Files are named to include the user and project, such as username-project-rc. For example, a finance project member named user would use the user-finance-rc file to obtain access to the Identity service API located at 172.25.250.50 and be authorized to work in the finance project:

[user@demo ~]$ cat user-finance-rc
export OS_USERNAME=user
export OS_PASSWORD=redhat
export OS_PROJECT_NAME=finance
export OS_PROJECT_DOMAIN_NAME=Default
export OS_USER_DOMAIN_NAME=Default
export OS_IDENTITY_API_VERSION=3
export OS_AUTH_URL=http://172.25.250.50:5000/v3

Each user must source the environment file to set the variables. OpenStack commands use these variables, when set, so that users do not have to enter them as parameters to each command.

[user@demo ~]$ source user-demo-rc

The OSC is a consistent way to manage Red Hat OpenStack Platform services. The openstack command supports command objects and actions to interact with Red Hat OpenStack Platform services to request resource operations and behavior.

[user@demo ~(user)]$ openstack command-object  command-action  command-arguments

For example, to list all available instances, use the openstack server list command. The -c Name and -c Status arguments reduce the output.

[user@demo ~(user)]$ openstack server list -c Name -c Status
+-----------------+--------+
| Name            | Status |
+-----------------+--------+
| finance-server2 | ACTIVE |
+-----------------+--------+

The list of available command objects is long, including objects from every RHOSP-supported OpenStack service. Objects can have multiple-word names. For example, floating ip, fixed ip, and security group are one object. Some objects mentioned in this lecture include user, project, server, flavor, image, volume, and network.

Command actions are defined with specific meaning to provide a consistent behavior for all objects. Actions are limited by the user's scope and any relevant role and service policies. Some actions are common to all objects:

To view a complete list of command options and actions, use openstack help. The output displays global options first and follows with the command object's action list with descriptions. This example shows command actions that are specific to the server object type.

[user@demo ~(user)]$ openstack help
...output omitted...
server add port      Add port to server
server create        Create a new server
server delete        Delete server(s)
server list          List servers
server pause         Pause server(s)
server remove port   Remove port from server
server set           Set server properties
server show          Show server details
server unpause       Unpause server(s)
server unset         Unset server properties
...output omitted...

Use the openstack help command to display the full syntax for a command object and action.

[user@demo ~(user)]$ openstack help server delete
usage: openstack server delete [-h] [--wait] <server> [<server> ...]

Delete server(s)

positional arguments:
  <server>    Server(s) to delete (name or ID)

optional arguments:
  -h, --help  show this help message and exit
  --wait      Wait for delete to complete

[user@demo ~(user)]$ openstack project list
+----------------------------------+------------+
| ID                               | Name       |
+----------------------------------+------------+
| 55ecbab943d64ae49d7b995dd4cabbb5 | production |
| 6dc0ec15468d47228d20d81d7bdd3302 | finance    |
+----------------------------------+------------+

[user@demo ~(user)]$ openstack network list
+--------------------------------------+---------------------+------------------
--------------------+
| ID                                   | Name                | Subnets
                    |
+--------------------------------------+---------------------+------------------
--------------------+
| 8799e43b-2848-4772-8c4c-c6545e54db19 | finance-network1    | c119fd6f-9211-458
b-9377-f2b840dbb76d |
| ef95203b-7c9f-46c0-b328-e51aa7729798 | provider-datacentre | 655df137-b2e3-4e3
d-9b52-98221b7abf24 |
+--------------------------------------+---------------------+------------------
--------------------+

[user@demo ~(user)]$ openstack network list --max-width 80
+---------------------------+---------------------+----------------------------+
| ID                        | Name                | Subnets                    |
+---------------------------+---------------------+----------------------------+
| 8799e43b-2848-4772-8c4c-c | finance-network1    | c119fd6f-9211-458b-9377-f2 |
| 6545e54db19               |                     | b840dbb76d                 |
| ef95203b-7c9f-46c0-b328-e | provider-datacentre | 655df137-b2e3-4e3d-9b52-98 |
| 51aa7729798               |                     | 221b7abf24                 |
+---------------------------+---------------------+----------------------------+

[user@demo ~(user)]$ openstack network list -c ID -c Name
+--------------------------------------+---------------------+
| ID                                   | Name                |
+--------------------------------------+---------------------+
| 8799e43b-2848-4772-8c4c-c6545e54db19 | finance-network1    |
| ef95203b-7c9f-46c0-b328-e51aa7729798 | provider-datacentre |
+--------------------------------------+---------------------+

[user@demo ~(user)]$ openstack network list -f json
[
  {
    "ID": "8799e43b-2848-4772-8c4c-c6545e54db19",
    "Name": "finance-network1",
    "Subnets": [
      "c119fd6f-9211-458b-9377-f2b840dbb76d"
    ]
  },
  {
    "ID": "ef95203b-7c9f-46c0-b328-e51aa7729798",
    "Name": "provider-datacentre",
    "Subnets": [
      "655df137-b2e3-4e3d-9b52-98221b7abf24"
    ]
  }
]

[user@demo ~(user)]$ openstack network list -f json | jq --raw-output \
≥ '.[] | select(.["Name"] == "finance-network1" ) | .["ID"]'
8799e43b-2848-4772-8c4c-c6545e54db19

To provide an isolated environment in which a unique cloud user or group of users can develop and deploy their application, domain operators create a project and configure it with the resources required for the application. Users assigned the admin role within a project can control user's access and privileges for that project. The member role can create or configure project resources and then launch an instance in the project using those resources.

Domain operators can also delegate the management of single projects to other cloud users, such as project owners and qualified application developers, by assigning them administrator privileges at the project scope. Project administrators can assign users to their projects and perform project management tasks that normal project member privileges do not allow.

In a self-service cloud user environment, project members create tenant networks for their own project use. Networks can also be shared between projects. Tenant networks can be routed to public networks, but because this minimal instance scenario does not require public access, a private tenant network is sufficient for a successful launch.

An OpenStack network object defines its network type and network layer 2 physical attributes, even for software-defined tenant networks. A network requires a subnet to define the layer 3 addressing attributes, such as the IP version, network address and subnet mask, and the use of DHCP, routing, and name resolution. These detailed networking concepts, including external and provider networks, are covered in later chapters.

An instance is a single, running virtual machine. A cloud application is typically constructed with multiple software components, each running as an instance, working together to provide an end-user service or interface. Instances are launched from an image, and can use both ephemeral (temporary) and persistent virtual disks to provide storage. In OpenStack, instances are referred to as servers.

An image is a file that contains a virtual disk with a bootable operating system installed. Images are loaded at launch onto empty virtual devices to create virtual boot disks. Red Hat provides verified Red Hat Enterprise Linux images for client use. Many vendors also provide their products on images for use in OpenStack. A libvirt-based RHOSP deployment uses two image formats, RAW and QCOW2. Generally, RAW is for performance and QCOW2 is for advanced image functionality. Additional third-party vendor image formats can be imported into RHOSP, and are converted to one of the standard image formats.

Because common images are typically shared across overclouds and projects, cloud operators or domain operators load images in advance and make them available for project use. Project members can also load their own customized images for private project use.

A flavor specifies the compute, memory, and storage capacity of launched instances. Cloud operators create flavors to define the available virtual hardware configuration for launching virtual machines, which then becomes the size of the launched virtual server. Project members must use one of the existing public or shared flavors, and do not create new flavors.

Launching a minimal instance requires that the desired image, flavor, network, and subnet objects already exist and are available to the project, and that the cloud user is an authorized project member with privileges sufficient to request each of those resource objects. As the domain operator, you verify that each resource is correctly configured in the overcloud, and then inform cloud users that they can launch instances.

[user@demo ~(user)]$ openstack server create --image rhel8 --flavor small \
> --network finance-network1 --wait finance-server1

When you run this command, the Compute service locates a compute node with sufficient capacity to host your instance, and schedules the launch to occur there. The Network service connects the instance to the network using an IP address from the DHCP range configured in its subnet. The Image service provides the image to load into a virtual block device from the Block Storage service. The resulting resized virtual disk is booted to a running server instance.

The --wait option causes the command prompt to return only after the server has become active or has failed. When manually launching instances from the command line, this is the recommended method to be certain that the launch is complete.

A server runs a specific application service or component. Typically, application developers and system administrators plan to access an instance using SSH or through the application's REST API on a predetermined port. However, network access methods require an instance to have a public IP address and additional configuration to enable authorized end-user access. In this scenario, the instance is launched without a secure, public configuration, requiring a different method to manage the instance.

OpenStack provides a VNC client to access the console of a running instance. This works with both text-only and graphical login screens. You can use openstack console url show command to locate the console URL for your running instance. Open a browser and navigate to this URL to display the VNC console. This method does not require the OpenStack Dashboard. Ping the DHCP server from the instance to confirm correct network operation.

For example:

[user@demo ~(user)]$ openstack console url show demo-server1
+-------+-----------------------------------------------------------+
| Field | Value                                                     |
+-------+-----------------------------------------------------------+
| type  | novnc                                                     |
| url   | http://172.25.250.50:6080/vnc_auto.html?path=             |
|       | tokenDbcdf9f9a-1b4a-467a-acd5-3647bd9215d6                |
+-------+-----------------------------------------------------------+

[user@demo ~(user)]$ firefox http://172.25.250.50:6080/vnc_auto.html?path=tokenDbcdf9f9a-1b4a-467a-acd5-3647bd9215d6

The previous command results in the following graphical display. This is not the OpenStack Dashboard, but only a browser-enabled VNC connection.

Figure 1.2: The VNC console in a browser

When this scenario's image was originally created, the root account was enabled with a known password. Later in this course, you will learn how a cloud user can inject a generated password into an instance at launch, to access instances when the root password is unknown.

The console messages normally displayed during system boot are captured in the instance's console log. From the command line, you can view the console log for information or diagnostics.

[user@demo ~(user)]$ openstack console log show finance-server1
...output omitted...
[[32m  OK  [0m] Started Network Manager Script Dispatcher Service.
         Starting Hostname Service...
[   37.327203] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[[32m  OK  [0m] Started Hostname Service.
[   39.425321] cloud-init[497]: Cloud-init v. 0.7.6 running 'init-local' at Tue,
 07 Mar 2017 12:05:05 +0000. Up 39.36 seconds.

Red Hat Enterprise Linux Server 7.3 (Maipo)
Kernel 3.10.0-514.6.1.el7.x86_64 on an x86_64

web image
host-192-168-1-10 login: [   52.312776] cloud-init[796]: Cloud-init v. 0.7.6 run
ning 'init' at Tue, 07 Mar 2017 12:05:18 +0000. Up 52.21 seconds.
...output omitted...

The Red Hat OpenStack Platform Dashboard is a web-based user interface for managing OpenStack resources, launching instances, and deploying applications. Accessing the Dashboard requires a URL, user name, and password. It supports both HTTP or HTTPS, for OpenStack deployments configured with secure protocols and certificates.

The Dashboard is located at http://dashboard.overcloud.example.com in your classroom. For initial and system-wide configuration, log in as admin using redhat as the password. In this course, always use the user name and password specified in your lab instructions.

Launching an instance from the Dashboard requires the same objects as from the command line. A recommended practice is to visually verify the user name and the current project in the upper-right corner of the Dashboard. You can be assigned to more than one project but you can only be active in one project at a time. Use the project chooser to verify that you have selected the correct project for the next task.

Navigate to Compute → Instances to locate the Launch Instance button. Observe that only four choices on the left menu are marked as mandatory. In the Details tab, enter an instance name and description.

Figure 1.3: The Launch Instance Details window

Set Create New Volume to No. The Compute service creates an ephemeral disk using the specified flavor sizing. Because it is an ephemeral disk, it is deleted when the server is deleted.

Figure 1.4: The Launch Instance Source window

To launch an instance the Source, Flavor, and Networks parameters must be set. Use the arrows on the right to move between sections. As mentioned previously, these resource object and launch process choices will be covered in detail in later chapters.

Figure 1.5: The Instances page with a spawning instance

The server instance appears on the Instances page, with a Build status and a Spawning task. If sufficient capacity exists and the overcloud is correctly configured, the instance will achieve an Active status. In the Actions column, choose Console from the list. The finance-server1 page displays, open to the Console tab. The Log tab to the left of the Console tab is the same log of console startup messages as was discussed when using command-line access.