Chapter 2. Troubleshooting OpenStack Identity

Keystone plays a crucial role in the OpenStack deployment. This project is responsible for providing services that support an identity, token management, a service catalog, and policy functionality. While Keystone does not depend on any other OpenStack services, most other OpenStack services depend on Keystone. This core dependency on Keystone means that problems with your Keystone services can cascade, causing problems for many of the other OpenStack services. Tracking down a problem in OpenStack can be complicated due to the different projects that operate together to provide a functionality. When troubleshooting OpenStack, it's smart to make sure that Keystone is operating as intended. In this chapter, we will explore the following topics:

• Identifying different versions of the Keystone API and how to avoid configuration problems

• Troubleshooting the command-line interface clients

• Checking the Identity API

• Fixing issues with the Keystone database...

Know your version

As of the Liberty release of OpenStack, the identity service finds itself in transition. The service supports two API versions: v2 and v3. The v2 version of the API is deprecated, but may still be found in many OpenStack deployments. Recent releases of OpenStack are configured to serve both the v2 and v3 versions of the Identity API. This can be confirmed by examining the keystone-paste.ini configuration file.

In this file, you will find configurations for two composite apps: main and admin. As demonstrated in the preceding example, each app has a setting for /v2.0 and /v3. With this configuration, this deployment will serve a request to the v2 or v3 Identity API. Here, the command-line clients transition from individual clients per project to a unified OpenStack client that works across projects. The keystone command-line client supports v2 of the Identity API. The newer and preferred OpenStack client supports v2 and v3 of the Identity API.

The two composite apps in the...

Running Keystone under Eventlet

If you are running Keystone using the Eventlet-based process, you will use the keystone-all command to start the Keystone services. This command will start both the Service API and the Administration API in a single process.

Checking the Keystone service

You can confirm that Keystone was started successfully by running ps -aux | grep keystone, which should show you several keystone-all processes. The output should look similar to the following output:

You can also check this by running pgrep -l keystone. The output from this command should look similar to this output:

Checking the Keystone client

You can use the openstack client or the keystone command-line client to double check whether Keystone is running properly. Before you use the client, make sure that you have sourced the credentials in your openrc file or be prepared to pass the required auth attributes in with the command. If you forget to take one of these steps, you may see an error like the following...

Summary

In this chapter, we looked at how to resolve common issues with the Identity service. We learned how to tell which version of the Keystone API we are using and also looked at how to use the command-line interface clients to troubleshoot. We made calls to the Identity API in order to confirm that Keystone was running as expected and learned to troubleshoot issues with the Keystone database. We also checked the service catalog to make sure endpoints were properly configured and successfully ran Keystone as a WSGI application under Apache.

Keystone plays a central role in the successful operation of an OpenStack cluster. Each of the other OpenStack services depend on Keystone and the functionality it provides. As a result, successful troubleshooters will need to make sure that Keystone is running correctly. In the next chapter, we will look at how to troubleshoot the OpenStack Image service, code named Glance.