We will create the user using the keystone command as shown in the following screenshot. The output will show the UID of the user created. Note that the UID generated will be a different one for you:

keystone user-create --name cinder --pass c1nd3rkeypwd

As the next step, we will add the user to the admin role in the service tenant that we created while installing Glance:

keystone user-role-add --user cinder --tenant service --role admin

This command doesn't provide any output, so if you see nothing, it is indeed good news!

We will create the service in Keystone so that Keystone can publish it to all the services that need it. However, in Cinder, we need to create two services, one each for version 1 and version 2.

keystone service-create --name cinder --type volume --description "OpenStack Block Storage"
keystone service-create --name cinderv2 --type volumev2 --description "OpenStack Block Storage"

You should see the following result:

We will also have to note down the IDs of both the services that we have used to create the endpoints, so note it down.

We will need to create two endpoints as well, one per service. At this point, you must know that Cinder uses 8776 as the default port.

keystone endpoint-create 
  --service-id a3e71c643105452cb4c8239d98b85245
  --publicurl http://OScontrollerNode:8776/v1/%(tenant_id)s 
  --internalurl http://OScontrollerNode:8776/v1/%(tenant_id)s 
  --adminurl http://OScontrollerNode:8776/v1/%(tenant_id)s 
  --region dataCenterOne

keystone endpoint-create 
  --service-id d9f4e0983eda4e8ab7a540441d3f5f87 
  --publicurl http://OScontrollerNode:8776/v2/%(tenant_id)s 
  --internalurl http://OScontrollerNode:8776/v2/%(tenant_id)s 
  --adminurl http://OScontrollerNode:8776/v2/%(tenant_id)s 
  --region dataCenterOne

You will notice that the URLs for this are different from the other endpoints so far. This is because it has the tenant ID as a variable, and the URL will be modified during runtime by the client using the endpoint.

We modify the configuration file located at /etc/cinder/cinder.conf. We will modify three sections:

Note that some sections themselves don't exist in the default configuration shipped with the distro. You should create them and add the options as follows:

The Cinder database will be populated using the following command:

/bin/sh -c "cinder-manage db sync" cinder

This command should be run as a root.

As a prerequisite, we will need to ensure the following:

As the first step, we will install the LVM tools to ensure we create the volume groups:

apt-get install lvm2

The next step in the process is to create a volume group on the second hard disk. If we are doing the install in a production environment, the second hard drive or the other drives will be a part of disk array and will be connected using FC or iSCSI. If we are using a VM for the production deployment, the storage node can be connected to the disks using virtual disks or even raw device mappings.

We should check the presence of the disks and that they can be detected by the storage node. This can be done executing the following command:

fdisk –l

In our case, you can see that we have sdb and sdc. We are going to use sdb for the Cinder service. We will create a partition on the sdb drive:

fdisk /dev/sdb

Create a new partition by using the menu and entering n for new partition and p for primary partition. Choose the defaults for other options. Finally, enter w to write to the disks and exit fdisk.

The following screenshot demonstrates the result:

As the next step, we will create an LVM physical volume:

pvcreate /dev/sdb1

On that, we will create a volume group called cinder-volumes:

vgcreate cinder-volumes /dev/sdb1

filter = [ "a/sda/","a/sdb/","r/.*/" ]

Next, we will add host entries to the /etc/hosts file so that OSControllerNode and OSStorageNode knows the IP address of each other.

After this, verify that both the servers are able to ping each other by name.

Now, let us look at the checklist for the configuration, presented as follows:

Before working on this node, ensure that you have added the Juno repository shown in Chapter 2, Authentication and Authorization Using Keystone.

We have already created the Cinder database when we were performing actions on the controller node, so we can directly start with installation of the packages.

We will install the cinder-volume package; we will install the Python client and drivers for MySQL, as this node will need to access the database on the controller node:

apt-get install cinder-volume python-mysqldb

Ensure that the installation is complete.

We will need to modify the /etc/cinder/cinder.conf file as we had done it on the controller node. We will modify the following sections:

It is going to be exactly same as we did in the controller node, except for the my_ip directive, which will in this case, have the IP address of the storage node rather than the controller node. The configuration modification will look like this:

[default]
rpc_backend = rabbit
rabbit_host = OSControllerNode
rabbit_password = rabb1tmqpass
auth_strategy = keystone
my_ip = 172.22.6.96
verbose = true

[database]
connection = mysql://cinder:c1nd3rpwd@OSControllerNode/cinder

[keystone_authtoken]
auth_uri = http://OScontrollerNode:5000/v2.0
identity_uri = http://OScontrollerNode:35357
admin_tenant_name = service
admin_user = cinder
admin_password = c1nd3rkeypwd

To finalize the installation, we will remove the SQLite db that came with the Ubuntu packages, as we will not use it:

rm -f /var/lib/cinder/cinder.sqlite

We will then restart the Linux target framework that controls iSCSI connections and then finally the cinder-volume itself:

service tgt restart
service cinder-volume restart

We now have completed the installation of Cinder.

We will perform a simple validation by executing the following commands on the controller node:

You should see something like the following:

The service-list will show all the nodes that take part in the Cinder service. As you can see, our two nodes show up, which is as expected. The cinder-list command shows us the virtual volumes that are created (to be connected to the Nova instances), but since we don't have any, we don't expect to see any output there.