A user is granted a role in a project. A project is simply a grouping of resources. A user can have a role in multiple projects. Without a role in a project, a user cannot create virtual resources in an OpenStack cluster. A user is useless without a role in a project. All virtual resources created in OpenStack must exist in a project. Virtual resources are the virtual infrastructure that OpenStack manages. Among others, instances, networks, storage, and disk images must exist in a project. Recall the services that were just introduced; they all have a user that has a role in a project. If you list the users and projects in your OpenStack installation, you will see a user for each of the components installed in the installed cluster. Then, list one of the user's roles in the service project. Let's use Nova as an example; here's the output summary after you hit the following commands:

undercloud# openstack user list
undercloud# openstack project list
undercloud# openstack user role list --project service nova 
+---------------+--------------+--------------------+-------------+
 |      id           |  name       |     Project        |     User     | +---------------+--------------+--------------------+-------------+ 
 |   {role_id}  | _member_ |   service          |    nova     |
 |   {role_id}  | admin       |    service         |    nova     |+---------------+--------------+--------------------+-------------+

There should not be any need for you to interact with these service users, though there are conventions that are used for creating users for you and end users to interact with the cluster. First, there are only two roles that are currently used, admin and member. administrative and non-administrative privileges respectively. Recall that when we authenticated the admin user earlier, the admin user was authenticating to a project named the same as the username. A common convention for creating project names is to use the same name as that of the user that will be using it unless it is used by a group. If there are multiple users that have roles in a project, a more descriptive name is used for the project's name. Take the admin and service projects as examples of using the user's name or a more descriptive name. There are multiple users in the service project. It is a project for all the users of services. There is only one user that uses the admin tenant – the admin user. Each user that will use an OpenStack deployment will need a user to log in and a project to operate out of. Each user can have a different role in different projects. Let's walk through creating a user and project and giving that user a role in the project.

We will start by creating a user. There are a handful of subcommands for user management. Run the openstack help subcommand on user and look through the list of subcommands available. To create a user, use the user-create subcommand as follows:

undercloud# openstack help user
undercloud# openstack user create danradez

A user now exists that has my first and last name as its username. There are other properties that can be set when a user is created. Use help in the command-line client to get more information about these properties, as follows:

undercloud# openstack help user create

All of OpenStack's command-line commands use this syntax convention to display help. You can use the subcommand help and pass it the subcommand name that you want help on, and a list of arguments and their descriptions will be displayed. An e-mail or a password could have been set when the user was created. All these properties can also be updated using the user set subcommand. Let's update the new user's e-mail as an example:

undercloud# openstack user set --email [email protected] danradez

Here, the new user has been updated to have an e-mail address. Next, set a password for the new user, as follows:

undercloud# openstack user set --password supersecret danradez

Now that we have a user, we need a project for the user to store its virtual resources. Similar to the subcommands for user management, you can get help on all the subcommands for project management with OpenStack's help subcommand. The following project create subcommand will create a new project for the new user:

undercloud# openstack project create danradez

In this example, the project is created using the convention mentioned earlier, with the username as the name of the project. A project also has a description property; use openstack help project create or keystone help project set to get the syntax to set the project's description.

Make a note that, on the command line, projects have historically been called tenants. If you see references to tenants while you are working with OpenStack, or even in this book, know that a project and a tenant are analogous.

Now that we have a user and a project, they need to be associated with each other with a role. To do this, the user, the project, and a role need to be passed to the role add subcommand. Before this is executed, you can use the role list command to get a list of roles, as shown in the following code:

undercloud# openstack role list
undercloud# openstack user role add --user danradez --project danradez _member_

This command associates the user, the project, and the role with each other. This association can now be displayed using the user role list subcommand used earlier, as follows:

undercloud# openstack user role list --project danradez danradez

That command will show you that the new user was granted the member role in the new project. Now that we have a new user that has a role in a project, we can use this user's password to make command-line API calls in the same way as was done with the admin user.

The easiest way to start using the new user is to make a copy of an existing overcloudrc file, update the values in it, and source the file. We conveniently already have an existing overcloudrc file that was used for the admin user. Make a copy of it and edit it so that its contents have values respective to your new user, as follows:

undercloud# cp overcloudrc overcloudrc_danradez

Here are the contents of the new file:

export OS_USERNAME=danradez
export OS_TENANT_NAME=danradez
export OS_PASSWORD=supersecret
export OS_AUTH_URL=http://192.0.2.6:5000/v2.0/

AUTH_URL here is pointing to the internal URL; the public URL is also a fine choice for this value. You can leave the other values that were in the overcloudrc file in there if you want.

A simple authentication verification is to issue the token issue command, as follows:

undercloud# source overcloudrc_danradez
undercloud# openstack token issue

Once you are able to authenticate, you can start to build your virtual infrastructure as a non-administrative user and create more accounts for other non-administrative users.