Centos Lab2 : Glance – Kilo

In this lab, you will install the OpenStack Image Service (aka Glance). This requires a similar set of steps as the Keystone installation, but we won’t have to re-install the database or message queue services, and we’ll be leveraging the Keystone service we installed in the previous lab.

OpenStack Image Service (Glance) provides discovery, registration, and delivery services for disk and server images. It offers a REST API that enables you to query Virtual Machine Images and their metadata. Images can be stored in a variety of locations from simple file systems to object-storage systems like Swift (OpenStack Object Storage).

As you install Glance observe the commands you are running during this process. Do you see any similarity between installing Keystone and this service?

Image Service Installation

Step 1: Log into your AIO node from the lab-gateway machine

If you have logged out, SSH into your AIO node:

ssh centos@aio110

If asked, the user password (as with the sudo password) would be centos, then become root via the sudo password:

sudo su -

Then we’ll source the OpenStack administrative user credentials. As you’ll recall from the previous lab, this sets a set of environment variables (OS_USERNAME, etc.) that are then picked up by the command line tools (like the keystone and glance tools we’ll be using in this lab) so that we don’t have to pass the equivalent –os-username command line variables for each command we run:

source ~/openrc.sh

So now we’re ready, and much like with Keystone, we’ll install both the glance components, and the python CLI tools:

yum install openstack-glance python-glanceclient -y

Create Database for Image Service

Step 2: Set up the database:

Glance stores information about images in a database, specifically the image location (file, object, etc. info), any uploaded metadata or tags associated with the image (e.g. specific parameters for the virtualization backend such as disk driver type, whether the image is publicly available, etc.), and a tenant association (i.e. who owns this image). We will create the glance database by logging into MariaDB as the root user with our pre-defined super secret password pass, and will pass the CREATE command along with the database user credentials creation commands. In this case we’re ensuring that either a local access request to localhost or to ‘%’ which is database shorthand for ‘any value’ or in our particular case, ‘any host’ can access the glance database. In reality we’ve configured our database to only allow access from the localhost address, or from the aio address, effectively limiting access to the local machine.

mysql -uroot -ppass
CREATE DATABASE glance;
GRANT ALL PRIVILEGES ON glance.* TO 'glance'@'localhost' IDENTIFIED BY 'pass';
GRANT ALL PRIVILEGES ON glance.* TO 'glance'@'%' IDENTIFIED BY 'pass';
exit

We will eventually have to migrate the database to the current state, but for now we’ll configure the User/Tenants in Keystone, and then once we’ve updated the glance configuration files, we’ll be able to do the migration.

Creating the Glance Service User

Since we don’t have to do a migration, we can move on to configuring the rest of glance, the first step will be to create a service account in Keystone to support programatic interaction between Glance and other OpenStack services.

Step 3: We will continue our super-secure model of using pass as the glance user password and will use another generic email address for the glance user:

openstack user create glance --password pass --email [email protected]

Example output:

+----------+----------------------------------+
| Property |              Value               |
+----------+----------------------------------+
|  email   |      [email protected]      |
| enabled  |               True               |
|    id    | b4d60c444360421ea4d4f4a8f958203e |
|   name   |              glance              |
| username |              glance              |
+----------+----------------------------------+

We will provide the glance user with the same admin role rights as our general admin user, but associated with the service tenant (this being the default expected tenant for inter-service RESTful communication in the OpenStack environment):

openstack role add --project service --user glance admin

Configure Image Service

Unlike Keystone, Glance is actually made up of two services, the glance-api service, which is what end-users, CLI tools, APIs communicate with and which manages talking to other services, like writing files to disk, object store, etc., and the glance-registry service, which manages the communications with the database.

Actually, this is the way it originally was. We’re now using the v2 api, and in the v2 api model, the database communication is handled by the API service directly. The registry service is there for backwards compatability to the glance v1 api, and there has been some interest in using it for other purposes (such as going back to a segregated engine for database communications).

Regardless, we will modify the .conf files for both services (glance-api.conf and glance-registry.conf respectively) to define their inter-process communications and database access credentials. We’ll also define the disk configuration for storing images loaded into Glance.

Step 4: Edit /etc/glance/glance-api.conf

First we will configure our RabbitMQ connection. We’re doing this for internal communication between the API process and it’s worker processes. There are components of the API service dedicated to managing data read/write processes that may be long lived, allowing for a more responsive API service.

openstack-config --set /etc/glance/glance-api.conf DEFAULT rpc_backend rabbit
openstack-config --set /etc/glance/glance-api.conf DEFAULT rabbit_host aio110
openstack-config --set /etc/glance/glance-api.conf DEFAULT rabbit_userid test
openstack-config --set /etc/glance/glance-api.conf DEFAULT rabbit_password test

Step 5: Configure the location of the database that was created in Step 2. Search for the [database] section and add the database connection information as follows:

openstack-config --set /etc/glance/glance-api.conf database connection mysql://glance:pass@aio110/glance

Glance needs to be able to talk to Keystone to validate user requests, so we will add the configuration for validating identity to the glance-api.conf file. Find the [keystone_authtoken] section and add the following immediately after the [keystone_authtoken] section header:

openstack-config --set /etc/glance/glance-api.conf keystone_authtoken auth_uri http://aio110:5000/v2.0
openstack-config --set /etc/glance/glance-api.conf keystone_authtoken identity_uri http://aio110:35357
openstack-config --set /etc/glance/glance-api.conf keystone_authtoken admin_tenant_name service
openstack-config --set /etc/glance/glance-api.conf keystone_authtoken admin_user glance
openstack-config --set /etc/glance/glance-api.conf keystone_authtoken admin_password pass

Next we configure the paste engine (this is actually the Python language framework that Glance is written in) to use the information in the keystone section. Find the [paste_deploy] section and add the following key under the [paste_deploy] header:

openstack-config --set /etc/glance/glance-api.conf paste_deploy flavor keystone

Step 6: Now edit /etc/glance/glance-registry.conf in the same way:

openstack-config --set /etc/glance/glance-registry.conf DEFAULT rpc_backend rabbit
openstack-config --set /etc/glance/glance-registry.conf DEFAULT rabbit_host aio110
openstack-config --set /etc/glance/glance-registry.conf DEFAULT rabbit_userid test
openstack-config --set /etc/glance/glance-registry.conf DEFAULT rabbit_password test
openstack-config --set /etc/glance/glance-registry.conf database connection mysql://glance:pass@aio110/glance
openstack-config --set /etc/glance/glance-registry.conf keystone_authtoken auth_uri http://aio110:5000/v2.0
openstack-config --set /etc/glance/glance-registry.conf keystone_authtoken identity_uri http://aio110:35357
openstack-config --set /etc/glance/glance-registry.conf keystone_authtoken admin_tenant_name service
openstack-config --set /etc/glance/glance-registry.conf keystone_authtoken admin_user glance
openstack-config --set /etc/glance/glance-registry.conf keystone_authtoken admin_password pass
openstack-config --set /etc/glance/glance-registry.conf paste_deploy flavor keystone

Define services and service endpoints

Register the glance with the keystone so that other OpenStack services can locate it. As stated earlier, the registry is really enabled specifically for supporting V1 API requests, and while we don’t expect much of that (or rather any), this is still considered “standard” practice. It may be that a future version of OpenStack no longer supports this, but for now we create the same effective configuration twice.

Normally we might also tweak the settings (in the api specificaly, as it was always the service that dealt with managing the actual images) for location of the image storage, such as configuring access to a SWIFT object store. But we’re going to use the default, which is already hard coded into the application. The images will be stored on disk in the /var/lib/glance/images directory, and after we load an image into glance, we can have a look and see that an image is in fact installed in that location.

Step 7: Register the service and create the endpoint.

Service endpoints let OpenStack services find each other, whether that be Nova looking for an image that was requested for a deployment, or a user uploading or downloading an image directly. The service endpoint is configured in Keystone, and much like Keystone’s own endpoint, there is a “standard” service that needs to exist called “glance” and with the type “image”. We’ll once again leverage the “keystone service-create” command to configure the service:

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

Example output:

+-------------+----------------------------------+
|   Property  |              Value               |
+-------------+----------------------------------+
| description |       OpenStack Image Service    |
|   enabled   |               True               |
|      id     | 1bc56754d0e34f11b2c959464a795a63 |
|     name    |              glance              |
|     type    |              image               |
+-------------+----------------------------------+

As with Keystone, we’ll create the service, and use the embedded lookup to get the correct service ID (we could have also copied it from the output of the previous command):

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

Example output:

+-------------+----------------------------------+
|   Property  |              Value               |
+-------------+----------------------------------+
|   adminurl  |        http://aio110:9292        |
|      id     | b8df5f714a6b4bd1a36081fc75c5b949 |
| internalurl |        http://aio110:9292        |
|  publicurl  |        http://aio110:9292        |
|    region   |            regionOne             |
|  service_id | 1bc56754d0e34f11b2c959464a795a63 |
|service_name | glance                           |
|service_type | image                            |  
+-------------+----------------------------------+

Step 8: Create the database tables for the Image Service

Now we’ll finalize the database internal structure before restarting the services. We’ll do this by passing the “db_sync” option to the glance-manage CLI tool. This populates the tables in the “glance” database that you created earlier using the connection information in the glance-api.conf file. Much like with Keystone, we’ll be running this command as the glance user, validating further our ability to talk to the database as the glance user:

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

Step 9: Enable and Start the glance service(s)

Again, as with Keystone, we’ll now enable the api and registry services, and then start them for the first time. If for some reason they had already started (which would be unusual), you could instead use “restart” in the second command.

systemctl enable openstack-glance-api.service openstack-glance-registry.service
systemctl start openstack-glance-api.service openstack-glance-registry.service
systemctl status openstack-glance-api.service openstack-glance-registry.service

Importing Images

Ok, now that Glance is running, let’s get it ready for use by other services. Specifially that means uploading an image into the glance repository. You may want to have a look at the glance image directory pre and post importing the image (or ‘image-create’ing an image).
ls /var/lib/glance/images should be empty to begin with, and then it should have a directory with a name that matches the ‘id’ that will be returned from the import command.

First, let’s get an image downloaded locally to import into Glance (this can now be done directly from a remote http(s): link too, but that is left as an exercise for the reader).
Step 10: Download the image into a dedicated directory using wget or curl:

Using wget:

First we’ll install wget:

yum -y install wget

mkdir images
cd images/
wget http://10.1.1.91/images/cirros-0.3.2-x86_64-disk.img

Step 11: Import the image into glance:

glance image-create --name "CirrOS 0.3.2" --disk-format qcow2 --container-format bare --is-public true --file cirros-0.3.2-x86_64-disk.img

Example output:

+------------------+--------------------------------------+
| Property         | Value                                |
+------------------+--------------------------------------+
| checksum         | 64d7c1cd2b6f60c92c14662941cb7913     |
| container_format | bare                                 |
| created_at       | 2015-05-07T03:31:42                  |
| deleted          | False                                |
| deleted_at       | None                                 |
| disk_format      | qcow2                                |
| id               | 66b3503e-57ee-46a6-ae6b-0f0b7e7eb693 |
| is_public        | True                                 |
| min_disk         | 0                                    |
| min_ram          | 0                                    |
| name             | CirrOS 0.3.2                         |
| owner            | 79af9405b769430d960c6ef47a30122e     |
| protected        | False                                |
| size             | 13167616                             |
| status           | active                               |
| updated_at       | 2015-05-07T03:31:42                  |
| virtual_size     | None                                 |
+------------------+--------------------------------------+

You can also check the image status by listing the currently available (to your tenant) list of images:

glance image-list

Where you might see something like:

+--------------------------------------+--------------+-------------+------------------+----------+--------+
| ID                                   | Name         | Disk Format | Container Format | Size     | Status |
+--------------------------------------+--------------+-------------+------------------+----------+--------+
| 66b3503e-57ee-46a6-ae6b-0f0b7e7eb693 | CirrOS 0.3.2 | qcow2       | bare             | 13167616 | active |
+--------------------------------------+--------------+-------------+------------------+----------+--------+

In this case, we’ll grab another copy directly from the web location:

glance image-create --name "cirros_0.3.2_direct" --disk-format qcow2 --container-format bare --is-public true --copy-from http://10.1.1.91/images/cirros-0.3.2-x86_64-disk.img --property openstack=cool

The output from the command lists back the currently known meta-data about this image, including elements like the type of container (generally “bare” as in there is no container for the disk), the type of disk (commonly qcow2, a “copy on write” format or raw, a copy of all of the bits that existed on the original volume), the public/private flag, the owner, the size, etc. No minimum amount of disk space or memory was defined (additional common meta-data), but we have provided a little bit of “other” metadata, specifically stating that the key “openstack” has value “cool”. Compare this to the previous image upload where no additional parameters were supplied.

Example output:

+----------------------+--------------------------------------+
| Property             | Value                                |
+----------------------+--------------------------------------+
| Property 'openstack' | cool                                 |
| checksum             | None                                 |
| container_format     | bare                                 |
| created_at           | 2015-05-07T03:43:36                  |
| deleted              | False                                |
| deleted_at           | None                                 |
| disk_format          | qcow2                                |
| id                   | 738aa06e-786d-402c-a0a1-cbe46a6c4b69 |
| is_public            | True                                 |
| min_disk             | 0                                    |
| min_ram              | 0                                    |
| name                 | cirros_0.3.2_direct                  |
| owner                | 79af9405b769430d960c6ef47a30122e     |
| protected            | False                                |
| size                 | 0                                    |
| status               | active                               |
| updated_at           | 2015-05-07T03:43:36                  |
| virtual_size         | None                                 |
+----------------------+--------------------------------------+

Now if you run the following command, you should see two versions of the cirros image:

glance image-list

Now that we have our image installed, and Glance is willing to give us information about it, we can clean up our local disk and return to the home directory:

cd
rm -rf images