Services and endpoints
Each one of the components in an OpenStack cluster is registered with Keystone. Each of the services has endpoints and each of the services has a user. A service in Keystone is a record of an OpenStack component that will need to be contacted to manage the virtual resources being managed by OpenStack. Endpoints are the URLs to contact these services. Let's look at this on the command line. Remember the overcloudrc file on the instack node? You'll need the information in that file to authenticate and interact with the OpenStack overcloud. The information is as follows:
undercloud# cat overcloudrc export OS_NO_CACHE=True export OS_CLOUDNAME=overcloud export OS_AUTH_URL=http://192.0.2.6:5000/v2.0 export NOVA_VERSION=1.1 export COMPUTE_API_VERSION=1.1 export OS_USERNAME=admin export no_proxy=,192.0.2.6 export OS_PASSWORD=mg4xQF4bnETuNgGGtp6t9CXMJ export PYTHONWARNINGS="ignore:Certificate has no, ignore:A true SSLContext object is not available" export OS_TENANT_NAME=admin
Use the information from the overcloudrc file to run this command:
control# openstack --os-username admin --os-tenant-name admin \ --os-password mg4xQF4bnETuNgGGtp6t9CXMJ --os-auth-url \http://192.0.2.6:5000/v2.0/ service list
Manually entering Keystone arguments is a real challenge and prone to error. The overcloudrc file thus becomes much more than just a storage place for the user's credentials. If you source the file, then those values are placed in the shell's environment. OpenStack's Python clients know to look at the shell's environment to get these values when they aren't passed as arguments. For example, execute the service-list command again with the overcloudrc file sourced, as follows:
undercloud# source overcloudrc undercloud# openstack service list
As you will see, it is much more manageable to issue this command and subsequent commands now. This list shows all the components that are registered with this OpenStack cluster. Now list the endpoints as follows:
control# openstack endpoint list
Each service has an endpoint record. Execute an endpoint show on one of the endpoints, as follows:
undercloud# openstack endpoint show cd94e1a6830e4110ba96217dc9177632
Each of the endpoint records has a public, private, and admin endpoint URL. Public is used for end user communication and the private and admin are used for internal communication between OpenStack components. An end user or a component within the cluster can always ask Keystone for the endpoint of a component, or service, to connect to. This makes it manageable to update the endpoints and be certain that new clients are connecting to the correct endpoints. The only endpoint that needs to be known ahead of time is the Keystone endpoint. Registration of a service and a set of endpoints only allows us to know about a service and how to connect to it. Each of these services also has a user. The services' users are used for inter-component communication. Each of the services authenticates with Keystone to communicate with each other.
Hierarchy of users, projects, and roles
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.
Creating a user
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 danradez@example.com 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
Creating a project
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.
Granting a role
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.
Logging in with the new 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.
Tip
Remember to use Keystone's service list and endpoint list commands if you want to use a different Keystone endpoint. Next, we must source the new keystonerc file. A simple authentication verification is to issue the command OpenStack token issue. If you get an error, it means that authentication failed.
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.