Keystone comes equipped with a SQLite database by default. Remove the database with the following command:

# rm -f /var/lib/keystone/keystone.db

Using the mysql client, create the Keystone database and associated user. When prompted for the root password, use openstack:

# mysql -u root -p

Enter the following SQL statements in the MariaDB [(none)] > prompt:

CREATE DATABASE keystone;
GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'localhost' IDENTIFIED BY 'keystone';
GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'%' IDENTIFIED BY 'keystone';
quit;

Before an administrative user has been configured in Keystone, an authorization token can be used as a shared secret between Keystone and other OpenStack services. When defined, the authorization token, admin_token, could be used to make changes to Keystone if an administrative user has not been configured or the password has been forgotten. Clients making calls to Keystone can pass the authorization token, which is then validated by Keystone before actions are taken.

Update the [DEFAULT] section in the /etc/keystone/keystone.conf file to set a simple admin token:

[DEFAULT]
...
admin_token = insecuretoken123

Keystone supports customizable token providers that can be defined within the [token] section of the configuration file. Keystone provides both UUID and PKI token providers. In this installation, the UUID token provider will be used. Update the token and revoke sections in the /etc/keystone/keystone.conf file accordingly:

[token]
...
provider = keystone.token.providers.uuid.Provider
driver = keystone.token.persistence.backends.memcache.Token
[revoke]
...
driver = keystone.contrib.revoke.backends.sql.Revoke

Populate the Keystone database using the keystone-manage utility:

# su -s /bin/sh -c "keystone-manage db_sync" keystone

Keystone now uses an HTTP server to process the Keystone API requests rather than a dedicated service. As a result, Apache must be configured accordingly.

Add the ServerName option to the Apache configuration file that references the short name of the controller node:

# sed -i '1s/^/ServerName controller01
&/' /etc/apache2/apache2.conf

Next, create a file named /etc/apache2/sites-available/wsgi-keystone.conf that includes virtual host definitions for the WSGI server:

# cat >> /etc/apache2/sites-available/wsgi-keystone.conf <<EOF
Listen 5000
Listen 35357

<VirtualHost *:5000>
    WSGIDaemonProcess keystone-public processes=5 threads=1 user=keystone display-name=%{GROUP}
    WSGIProcessGroup keystone-public
    WSGIScriptAlias / /var/www/cgi-bin/keystone/main
    WSGIApplicationGroup %{GLOBAL}
    WSGIPassAuthorization On
    <IfVersion >= 2.4>
      ErrorLogFormat "%{cu}t %M"
    </IfVersion>
    LogLevel info
    ErrorLog /var/log/apache2/keystone-error.log
    CustomLog /var/log/apache2/keystone-access.log combined
</VirtualHost>

<VirtualHost *:35357>
    WSGIDaemonProcess keystone-admin processes=5 threads=1 user=keystone display-name=%{GROUP}
    WSGIProcessGroup keystone-admin
    WSGIScriptAlias / /var/www/cgi-bin/keystone/admin
    WSGIApplicationGroup %{GLOBAL}
    WSGIPassAuthorization On
    <IfVersion >= 2.4>
      ErrorLogFormat "%{cu}t %M"
    </IfVersion>
    LogLevel info
    ErrorLog /var/log/apache2/keystone-error.log
    CustomLog /var/log/apache2/keystone-access.log combined
</VirtualHost>
EOF

Once complete, enable the virtual hosts for the Identity service with the following command:

# ln -s /etc/apache2/sites-available/wsgi-keystone.conf /etc/apache2/sites-enabled

Create a directory structure for the WSGI components:

# mkdir -p /var/www/cgi-bin/keystone

Then, copy the WSGI components from the upstream Kilo repository to the new directory using curl:

# curl http://git.openstack.org/cgit/openstack/keystone/plain/httpd/keystone.py?h=stable/kilo | tee /var/www/cgi-bin/keystone/main /var/www/cgi-bin/keystone/admin

Adjust the ownership and permissions of the files just created:

# chown -R keystone:keystone /var/www/cgi-bin/keystone 
# chmod 755 /var/www/cgi-bin/keystone/*

Finally, restart the Apache web service for the changes to take effect:

# service apache2 restart

Each OpenStack service that is installed should be registered with Keystone so that its location on the network can be tracked. There are two commands involved in registering a service:

Typically, a username and password is used to authenticate against Keystone. As users have not yet been created, it is necessary that you use the authorization token created earlier. The token can be passed using the --os-token option of the Keystone command or by setting the OS_TOKEN environment variable. We will use both the OS_TOKEN and OS_URL environment variables to provide the authorization token and to specify where the Keystone service is running.

Use the export command to export the variables and their values to your environment. OS_TOKEN should be set to the admin token value determined earlier:

# export OS_TOKEN=insecuretoken123
# export OS_URL=http://controller01:35357/v2.0

Keystone itself is among the services that must be registered. You can create a service entry for Keystone with the following command:

# openstack service create --name keystone --description "OpenStack Identity" identity

The resulting output is as follows:

Figure 2.2

Next, specify an API endpoint for the Identity service. When specifying an endpoint, you must provide URLs for the public API, internal API, and the admin API. The three URLs can potentially be on three different IP networks depending on your network setup and can have different hostnames. The short name of the controller will be used to populate the URLs. Each host can reference the other based on the hostname via DNS or the local /etc/hosts entries created earlier:

# openstack endpoint create 
  --publicurl http://controller01:5000/v2.0 
  --internalurl http://controller01:5000/v2.0 
  --adminurl http://controller01:35357/v2.0 
  --region RegionOne 
  identity

The resulting output is as follows:

Figure 2.3

Once the installation of Keystone is complete, it is necessary to set up domains, users, projects (tenants), roles, and endpoints that will be used by various OpenStack services.

In Keystone, a project or tenant represents a logical group of users to which resources are assigned. The terms "project" and "tenant" are used interchangeably throughout various OpenStack services. Resources are assigned to projects and not directly to users. Create an admin project for the administrative user, a demo project for regular users, and a service project for other OpenStack services to use:

# openstack project create --description "Admin Project" admin
# openstack project create --description "Service Project" service
# openstack project create --description "Demo Project" demo 

Next, create an administrative user called admin. Specify a secure password for the admin user:

# openstack user create admin --password=secrete

Once the admin user has been created, create a role for administrative tasks called admin:

# openstack role create admin

Any roles that are created should map to roles specified in the policy.json files of the corresponding OpenStack services. The default policy files use the admin role to allow access to services.

Associate the admin role to the admin user in the admin project:

# openstack role add --project admin --user admin admin

Create a regular user called demo. Specify a secure password for the demo user:

# openstack user create demo --password=demo

Create the user role:

# openstack role create user

Finally, add the user role to the demo project and user:

# openstack role add --project demo --user demo user

To verify that Keystone was installed and configured properly, use the unset command to unset the OS_TOKEN and OS_URL environment variables. These variables are only needed to bootstrap the administrative user and to register the Keystone service:

# unset OS_TOKEN OS_URL

Once the environment variables are unset, it should be possible to use username-based authentication. Request an authentication token using the admin user and the password specified earlier:

# openstack --os-auth-url http://controller01:35357 --os-project-name admin --os-username admin --os-password secrete token issue

Keystone should respond with a token that is paired with the specified user ID. This verifies that the user account is established in Keystone with the expected credentials:

Figure 2.4

As the admin user, request a list of projects to verify that the admin user can execute admin-only CLI commands and that the Identity service contains all of the projects created earlier in this chapter:

# openstack --os-auth-url http://controller01:35357 
  --os-project-name admin --os-username admin 
  --os-password secrete project list

The command will result in the following output:

Figure 2.5

You should receive a list of projects containing the admin, demo, and service projects created earlier in the chapter.

To avoid having to provide credentials every time you run an OpenStack command, create a file containing environment variables that can be loaded at any time. The following commands will create a file named adminrc containing environment variables for the admin user:

# cat >> ~/adminrc <<EOF
export OS_PROJECT_DOMAIN_ID=default
export OS_USER_DOMAIN_ID=default
export OS_PROJECT_NAME=admin
export OS_TENANT_NAME=admin
export OS_USERNAME=admin
export OS_PASSWORD=secrete
export OS_AUTH_URL=http://controller01:35357/v3
EOF

The following commands will create a file named demorc containing environment variables for the demo user:

# cat >> ~/demorc <<EOF
export OS_PROJECT_DOMAIN_ID=default
export OS_USER_DOMAIN_ID=default
export OS_PROJECT_NAME=demo
export OS_TENANT_NAME=demo
export OS_USERNAME=demo
export OS_PASSWORD=demo
export OS_AUTH_URL=http://controller01:5000/v3
EOF 

Use the source command to load the environment variables from the file. To test Keystone, issue the following commands:

# source ~/adminrc
# openstack user list

As the admin user, Keystone should return the user list as requested:

Figure 2.6

As the demo user, access is denied:

Figure 2.7

Depending on the command, non-admin users may not have appropriate access.

Glance comes equipped with a SQLite database by default. Remove the database with the following command:

# rm -f /var/lib/glance/glance.sqlite

Using the mysql client, create the Keystone database and associated user. When prompted for the root password, use openstack:

# mysql -u root -p

Enter the following SQL statements in the MariaDB [(none)] > prompt:

CREATE DATABASE glance;
GRANT ALL PRIVILEGES ON glance.* TO 'glance'@'localhost' IDENTIFIED BY 'glance';
GRANT ALL PRIVILEGES ON glance.* TO 'glance'@'%' IDENTIFIED BY 'glance';
quit;

Update the [database] connection string in the glance-api configuration file found at /etc/glance/glance-api.conf to use the previously defined MySQL database:

[database]
...
connection = mysql://glance:glance@controller01/glance

Repeat the process for the glance-registry configuration file found at /etc/glance/glance-registry.conf:

[database]
...
connection = mysql://glance:glance@controller01/glance

Add the glance user to Keystone and create the appropriate role:

# openstack user create --password glance glance
# openstack role add --project service --user glance admin

Both the glance-api and glance-registry service configuration files must be updated with the appropriate authentication settings for the services to operate.

Update the [keystone_authtoken] settings in the glance-api configuration file found at /etc/glance/glance-api.conf:

[keystone_authtoken]
...
auth_uri = http://controller01:5000/v2.0
auth_url = http://controller01:35357
auth_plugin = password
user_domain_id = default
project_domain_id = default
project_name = service
username = glance
password = glance 

Repeat the process for the glance-registry configuration file found at /etc/glance/glance-registry.conf:

[keystone_authtoken]
...
auth_uri = http://controller01:5000/v2.0
auth_url = http://controller01:35357
auth_plugin = password
user_domain_id = default
project_domain_id = default
project_name = service
username = glance
password = glance 

Update the glance-api configuration file found at /etc/glance/glance-api.conf with the following additional settings:

[paste_deploy]
...
flavor = keystone

[glance_store]
...
default_store = file
filesystem_store_datadir = /var/lib/glance/images

[DEFAULT]
...
notification_driver = noop

Update the glance-registry configuration file found at /etc/glance/glance-registry.conf with the following additional settings:

[paste_deploy]
...
flavor = keystone

[DEFAULT]
...
notification_driver = noop

Populate the Glance database using the glance-manage utility:

# su -s /bin/sh -c "glance-manage db_sync" glance

Restart the Glance services with the following commands:

# service glance-registry restart
# service glance-api restart

Like other OpenStack services, Glance should be added to the Keystone database using the openstack service create and endpoint create commands:

# openstack service create --name glance 
  --description "OpenStack Image service" image

The resulting output can be seen as follows:

Figure 2.8

Create the Glance API endpoints with the following command:

# openstack endpoint create 
  --publicurl http://controller01:9292 
  --internalurl http://controller01:9292 
  --adminurl http://controller01:9292 
  --region RegionOne 
  image

The resulting output is as follows:

Figure 2.9

Update each environment script created earlier in the chapter to define an environment variable that instructs the OpenStack client to use v2 of the Glance API:

# echo "export OS_IMAGE_API_VERSION=2" | tee -a ~/adminrc ~/demorc

Source the adminrc script to set or update the environment variables:

# source ~/adminrc

To verify that Glance was installed and configured properly, download a test image from the Internet and verify that it can be uploaded to the image server:

# mkdir /tmp/images
# wget -P /tmp/images http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img

Upload the image to Glance using the following command:

# glance image-create --name "cirros-0.3.4-x86_64" 
  --file /tmp/images/cirros-0.3.4-x86_64-disk.img 
  --disk-format qcow2 --container-format bare 
  --visibility public --progress

Verify that the image exists in Glance using the openstack image list or glance image-list command:

Figure 2.10

The CirrOS image is limited in functionality and is recommended only for testing network connectivity and operational Compute functionality. Multiple vendors provide cloud-ready images for use with OpenStack:

To install the Ubuntu 14.04 LTS image, download the file to /tmp/images and upload it to Glance:

# wget -P /tmp/images https://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64-disk1.img

Use the Glance image-create command to upload the new image:

# glance image-create --name "Ubuntu 14.04 LTS Cloud Image" 
  --file /tmp/images/trusty-server-cloudimg-amd64-disk1.img 
  --disk-format qcow2 --container-format bare 
  --visibility public --progress

Another look at the image list shows that the new Ubuntu image is available for use:

Figure 2.11

Execute the following command on the controller node to install the various Nova Compute services used by the controller:

# apt-get install nova-api nova-cert nova-conductor 
  nova-consoleauth nova-novncproxy nova-scheduler python-novaclient

Nova comes equipped with a SQLite database by default. Remove the database with the following command:

# rm -f /var/lib/nova/nova.sqlite

Using the mysql client, create the Nova database and associated user. When prompted for the root password, use openstack:

# mysql -u root -p

Enter the following SQL statements in the MariaDB [(none)] > prompt:

CREATE DATABASE nova;
GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'localhost' IDENTIFIED BY 'nova';
GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'%' IDENTIFIED BY 'nova';
quit;

Update the [database] section of the Nova configuration file found at /etc/nova/nova.conf to set the connection string to use the previously configured MySQL database:

[database]
...
connection = mysql://nova:nova@controller01/nova

Update the [DEFAULT] and [oslo_messaging_rabbit] sections of the Nova configuration file to configure Nova to use the RabbitMQ message broker:

[DEFAULT]
...
rpc_backend = rabbit

[oslo_messaging_rabbit]
...
rabbit_host = controller01
rabbit_userid = openstack
rabbit_password = rabbit

VNC Proxy is an OpenStack component that allows users to access their instances through VNC clients. VNC stands for virtual network computing and is a graphical desktop-sharing system that uses the Remote Frame Buffer protocol to control another computer over a network. The controller must be able to communicate with compute nodes for VNC services to work properly through the Horizon dashboard or other VNC clients.

Update the [DEFAULT] section of the Nova configuration file to configure the appropriate VNC settings for the controller node:

[DEFAULT]
...
my_ip = 10.254.254.100
vncserver_listen = 10.254.254.100
vncserver_proxyclient_address = 10.254.254.100

Create a user called nova in Keystone. The Nova service will use this user for authentication. After this, associate the user with the service project and give the user the admin role:

# openstack user create --password nova nova
# openstack role add --project service --user nova admin

Update the Nova configuration file at /etc/nova/nova.conf with the following Keystone-related attributes:

[DEFAULT]
...
auth_strategy = keystone

[keystone_authtoken]
...
auth_uri = http://controller01:5000
auth_url = http://controller01:35357
auth_plugin = password
project_domain_id = default
user_domain_id = default
project_name = service
username = nova
password = nova

You must then register Nova with the Identity service so that other OpenStack services can locate it. Register the service and specify the endpoint:

# openstack service create --name nova --description "OpenStack Compute" compute

The resulting output should resemble the output shown here:

Figure 2.12

Create the Nova endpoint with the following command:

# openstack endpoint create 
  --publicurl http://controller01:8774/v2/%(tenant_id)s 
  --internalurl http://controller01:8774/v2/%(tenant_id)s 
  --adminurl http://controller01:8774/v2/%(tenant_id)s 
  --region RegionOne 
  compute

The output should resemble the one shown here:

Figure 2.13

Update the Nova configuration file at /etc/nova/nova.conf to specify the controller node as the Glance host:

[glance]
...
host = controller01

Update the Nova configuration file to set the lock file path for Nova services:

[oslo_concurrency]
...
lock_path = /var/lib/nova/tmp

Populate the Nova database using the nova-manage utility:

# su -s /bin/sh -c "nova-manage db sync" nova

Restart the controller-based Nova services for the changes to take effect:

# service nova-api restart
# service nova-cert restart
# service nova-consoleauth restart
# service nova-scheduler restart
# service nova-conductor restart
# service nova-novncproxy restart

Once the controller-based Nova services have been configured on the controller node, at least one other host must be configured as a compute node. The compute node receives requests from the controller node to host virtual machine instances. Separating the services by running dedicated compute nodes means that Nova compute services can be scaled horizontally by adding additional compute nodes, once all available resources have been utilized.

On the compute nodes, install the nova-compute package and related packages. These packages provide virtualization support services to the compute node:

# apt-get install nova-compute sysfsutils

Update the Nova configuration file at /etc/nova/nova.conf on the compute nodes with the following Keystone-related attributes:

[DEFAULT]
...
auth_strategy = keystone

[keystone_authtoken]
...
auth_uri = http://controller01:5000
auth_url = http://controller01:35357
auth_plugin = password
project_domain_id = default
user_domain_id = default
project_name = service
username = nova
password = nova

Next, update the [DEFAULT] and [oslo_messaging_rabbit] sections of the Nova configuration file to configure Nova to use the RabbitMQ message broker:

[DEFAULT]
...
rpc_backend = rabbit

[oslo_messaging_rabbit]
...
rabbit_host = controller01
rabbit_userid = openstack
rabbit_password = rabbit

Then, update the Nova configuration file to provide remote console access to instances through a proxy on the controller node. The remote console is accessible through the Horizon dashboard. The IP configured as my_ip should be the respective management IP of each compute node:

Compute01:

[DEFAULT]
...
my_ip = 10.254.254.101
vncserver_proxyclient_address = 10.254.254.101
vnc_enabled = True
vncserver_listen = 0.0.0.0
novncproxy_base_url = http://controller01:6080/vnc_auto.html

Compute02:

[DEFAULT]
...
my_ip = 10.254.254.102
vncserver_proxyclient_address = 10.254.254.102
vnc_enabled = True
vncserver_listen = 0.0.0.0
novncproxy_base_url  http://controller01:6080/vnc_auto.html

[glance]
...
host = controller01

[oslo_concurrency]
...
lock_path = /var/lib/nova/tmp

# service nova-compute restart

To check the status of Nova services throughout the environment, use the Nova service-list command on the controller node as follows:

# nova service-list

The command should return statuses on all Nova services that have checked in:

Figure 2.14

In the preceding output, the state of the services on both the controller and compute nodes are reflected under the Status column. The nova service-list command can be run on any node in the environment, but will require proper authentication credentials. If there are inconsistencies in the output among multiple nodes, it's worth ensuring that Network Time Protocol (NTP) is synchronized properly on all nodes.

Edit the /etc/openstack-dashboard/local_settings.py file to set the hostname of the Identity server. In this installation, the Keystone services are running on the controller node. Change the OPENSTACK_HOST value from its default to the following:

OPENSTACK_HOST = controller01

The OPENSTACK_KEYSTONE_DEFAULT_ROLE setting in the /etc/openstack-dashboard/local_settings.py file must also be modified before the dashboard can be used. Change the OPENSTACK_KEYSTONE_DEFAULT_ROLE value from its default to the following:

OPENSTACK_KEYSTONE_DEFAULT_ROLE = "user"

Save and close the file.

Once the preceding changes have been made, reload the Apache web server configuration using the following command:

# service apache2 reload

By default, installations of the OpenStack dashboard on Ubuntu include a theme that has been customized by Canonical. To remove the theme, execute the following command:

# apt-get remove openstack-dashboard-ubuntu-theme

The examples in this book assume that the custom theme has been uninstalled.

From a machine that has access to the management network of the controller node, open http://controller01/horizon/ in a web browser.

The API network is reachable from my workstation, and the /etc/hosts file on my client workstation has been updated to include the same hostname-to-IP mappings configured earlier in this chapter. The following screenshot demonstrates a successful connection to the dashboard. The username and password were created in the Defining users, tenants, and roles in Keystone section earlier in this chapter. In this installation, the username is admin and the password is secrete:

Figure 2.15

Once you have successfully logged in, the dashboard defaults to the Admin tab. From here, information about the environment is provided in a graphical format. Looking at the following screenshot, the System Information panel provides the user with information about the environment, including Services and Compute Services. The services listed in the following screenshot are services that were installed earlier in this chapter:

Figure 2.16

To view the status of Nova Compute services, click on the Compute Services tab. This will return output similar to that of nova service-list in the CLI:

Figure 2.17