So far, we have used the GUI for all cloud activities.
OpenStack also features a commandline interface, which we are going to
explore in this section. We will also learn how OpenStack manages identities.
First, we need to clarify a few OpenStack identity concepts,
in particular, users and projects. We will then talk about the commandline clients.
Plural, yes, because there is more than one client.
We will then run a few commands to show the general logic that these clients follow.
Finally, how does authentication work when you use the commandline and
you don't have a login screen?
When you log onto the GUI, you provide your credentials, username and password.
The first screen you see when logging on is an overview of your resources.
So many CPUs, so much RAM, so many volumes, and gigabytes of storage,
and so on. These resources are actually not the demo user's
resources, but they belong to a project of which the demo user is a member.
You can see current project membership in the upper-left dropdown menu.
You will later see that you can use this menu to switch projects.
For now, only one project is available named demo, just like the user.
But what is a project?
For example, imagine a project to travel to Titan, the satellite of
Saturn that is suspected to harbor life. Several people work as
members of that project, and they use an OpenStack cloud for their data processing.
But cloud resources are not assigned to the individual users,
obviously they must be assigned to the Titan project.
Although the title of this course is Using, not Managing an OpenStack
Cloud, I will now become a cloud administrator for a short moment.
I'm logging onto the GUI as admin, which is traditionally the name of
the cloud super user, similar to root on a Unix or Linux system.
This is a list of all projects that are currently existing on this Packstack cloud.
There is a project for the admin user, a demo project, and a very
special project named services, whose members are not human, but OpenStack services.
Notice the term tenant in the descriptions, it's an old term for
project that is still used sometimes. Let's create a project for our
voyage to Titan. Please note that only a cloud administrator can add projects.
At this screen, all we need to enter is the name, and I will now fill
this project with members, actually with a single member only, namely user demo.
In the Quota section, I could now change the resource limits for this
project, but I will leave them alone. I will now log out and log on
as user demo again. Have a look at the upper-left dropdown menu,
it allows me now to change between the two projects on the fly,
and I'm now Titan. And as you can see, the Titan project is currently
not using any resources with the exception of one security group.
Projects are useful for allocating resources in a private cloud.
In a public cloud, the situation is a bit more complicated.
Imagine a company that uses a public cloud for all its IT.
You don't want to fill in a request to cloud administration each time
you launch a new project or you complete one.
Likewise, you want to add or otherwise manage your users.
To permit this, OpenStack has the domain concept, the company gets a
domain assigned in the public cloud and appoints a domain administrator.
This user can manage users and projects in the domain without asking for permissions.
Since the Red Hat OpenStack platform is targeted to private clouds
where the domain concept is of less value, we won't explore it in depth.