OpenStack Operations and Administration Roles

The users of an OpenStack cluster are not end-users, they are IT professionals, usually with an operations-focused job role. It is true that application developers sometimes have access to OpenStack clusters and manage their own VMs, but there they are acting as OpenStack Operators.

For the purpose of the Red Hat OpenStack training courses, we distinguish between two kinds of OpenStack users:

If you are new to OpenStack it’s recommended that you gain experience as an OpenStack Operator before taking responsibility for OpenStack Administrator tasks. An OpenStack Administrator can also perform, according to needs, the tasks of OpenStack Operators. In fact, OpenStack Administrators are typically expected to have all the skills and experience of OpenStack Operators.

Depending on the size of an organization, OpenStack users can either perform other IT roles by themselves or work closely with IT professionals from other roles. For example, an OpenStack Operator may also be the System Administrator who manages the RHEL operating system inside a server instance.

As a counter-example, an OpenStack Operator may delegate the configuration of the operating system inside a server instance to a Database Administrator, who is responsible for the database server running inside that server instance. OpenStack Operators usually work closely with DevOps Engineers, Email Administrators, ERP Administrators, and other IT roles focused on application development or application management.

Similarly, an OpenStack Administrator may also be an OpenShift Administrator. As a counter-example, an OpenStack Administrator may work closely with a RHEL Systems Administration team responsible for physical servers in the organization, including compute nodes of an OpenStack cluster. OpenStack Administrators usually work closely with Storage Administrators, Network Administrators, and other IT Operations roles focused on data center infrastructure and platforms.

In smaller organizations, the same team performs both OpenStack Operator and Administrator roles. In larger organizations, multiple teams of OpenStack Operators might be responsible for different group’s workloads running on the same cluster. Conversely, a larger OpenStack Administration team might split into subteams that manage different availability zones or compute cells of a single cluster.

The scope of work of an OpenStack Operator or Administrator usually includes multiple clusters. It’s unlikely that an organization will run all its workloads and put all its physical servers in a single OpenStack cluster. More frequently, there will be multiple clusters that run instances (or copies) of the same workloads, to be closer to their end users or for high availability purposes.

OpenStack Operators focus on OpenStack API resources and typically use the OpenStack client, which is a command-line (CLI) tool, and the web interface from OpenStack Horizon. The next section of this course provides an introduction to these tools. For now, stay focused on the OpenStack user job roles.

The OpenStack client, Horizon, and any other tools available from the open source community or IT vendor to manage OpenStack clusters and workloads rely on the same OpenStack APIs. There are no "backdoors", no "native" or "low-level" ways of managing OpenStack clusters.

Notice that OpenStack Operators are shielded from the fact that an OpenStack cluster runs its control plane on OpenShift. They do not require direct access to OpenShift. They are able to work around application performance and availability issues using OpenStack APIs, for example by migrating a server instance to a different compute node, or by connecting a server instance to a different virtual network. All the information they need to perform their daily job is available from OpenStack APIs, along with all the actions they must perform. They are concerned only with the user-facing services of OpenStack.

OpenStack Operators gradually grow into OpenStack Administrators because they can perform, using OpenStack APIs, tasks that impact multiple workloads and even entire clusters. Then they start requiring direct access to configure and manage OpenStack control planes, that is, to the OpenStack containers running on OpenShift, and to configure and manage compute nodes running RHEL.

OpenStack Administrators have a split focus among OpenStack APIs, Kubernetes APIs, Linux, and Ansible. They perform some tasks using the OpenStack client and Horizon, but for other tasks, they must use the OpenShift tools. And, because an OpenStack control plane uses Ansible playbooks to manage OpenStack compute nodes running RHEL, OpenStack Administrators also need skills in RHEL system administration using Ansible.

For simplicity, the previous figure omits the tools OpenStack Administrators use to interact with Kubernetes APIs and OpenShift clusters, such as:

In fact, OpenStack itself is packaged as an add-on operator for ease of installation on OpenShift.

OpenStack Administrators absolutely require skills in OpenShift, containers, and Kubernetes. They need those skills to install, configure, and troubleshoot OpenStack Services on OpenShift and also to manage OpenStack infrastructure services that are not user-facing and not accessible through OpenStack APIs.

OpenStack administrators are discouraged from manually managing compute nodes using SSH sessions. Instead, they should use Ansible as managed by OpenStack. Occasionally, OpenStack Administrators open SSH sessions directly to compute nodes for troubleshooting purposes.

Nowadays all IT roles require automation, either using traditional scripting, modern infrastructure-as-code, or even newer AI-enabled tools. Whatever the tool, if its purpose is automating the management of applications running on OpenStack, it is automating the same tasks a human OpenStack Operator would perform, and those tools must use the same OpenStack APIs.

Nothing prevents automation tools from running inside an OpenStack cluster. The OpenStack service named Heat, which is included with Red Hat OpenStack Services on OpenShift, is one of such tools. Most tools, for example, CI/CD managers, and infrastructure automation such as Ansible, can run either outside or inside an OpenStack cluster. And, if they run inside a cluster, nothing prevents them from managing other clusters.

Automation tools can also run in Kubernetes, as containers. In fact, the ability to use tools already included with Red Hat OpenShift, such as OpenShift Pipelines, is another advantage of running OpenStack control planes on OpenShift, opening the possibility of managing all applications used to support IT infrastructure using the same set of Kubernetes primitives and workflows.