Service Catalog

OpenStack services can be discovered when registered in keystone’s
service catalog. The service catalog can be managed as either a static
file template or as a dynamic database table.

File-based Service
Catalog (templated.Catalog)

The templated catalog is an in-memory backend initialized from a
read-only template_file. Choose this option only if you
know that your service catalog will not change very much over time.

keystone.conf example:

[catalog]
driver = templated
template_file = /opt/stack/keystone/etc/default_catalog.templates

The value of template_file is expected to be an absolute
path to your service catalog configuration. An example
template_file is included in keystone, however you should
create your own to reflect your deployment.

SQL-based Service Catalog
(sql.Catalog)

A dynamic database-backed driver fully supporting persistent
configuration.

keystone.conf example:

[catalog]
driver = sql

To build your service catalog using this driver, see the built-in
help:

$ openstack --help
$ openstack service create --help
$ openstack endpoint create --help

Create a service

1. List the available services:

   $ openstack service list
   +----------------------------------+----------+------------+
   | ID                               | Name     | Type       |
   +----------------------------------+----------+------------+
   | 9816f1faaa7c4842b90fb4821cd09223 | cinder   | volume     |
   | 1250f64f31e34dcd9a93d35a075ddbe1 | cinderv2 | volumev2   |
   | da8cf9f8546b4a428c43d5e032fe4afc | ec2      | ec2        |
   | 5f105eeb55924b7290c8675ad7e294ae | glance   | image      |
   | dcaa566e912e4c0e900dc86804e3dde0 | keystone | identity   |
   | 4a715cfbc3664e9ebf388534ff2be76a | nova     | compute    |
   | 1aed4a6cf7274297ba4026cf5d5e96c5 | novav21  | computev21 |
   | bed063c790634c979778551f66c8ede9 | neutron  | network    |
   | 6feb2e0b98874d88bee221974770e372 |    s3    |    s3      |
   +----------------------------------+----------+------------+

2. To create a service, run this command:

   $ openstack service create --name SERVICE_NAME --description SERVICE_DESCRIPTION SERVICE_TYPE

   The arguments are:

   • service_name: the unique name of the new service.
   • service_type: the service type, such as
     identity, compute, network,
     image, object-store or any other service
     identifier string.
   • service_description: the description of the
     service.

   For example, to create a swift service of type
   object-store, run this command:

   $ openstack service create --name swift --description "object store service" object-store
   +-------------+----------------------------------+
   | Field       | Value                            |
   +-------------+----------------------------------+
   | description | object store service             |
   | enabled     | True                             |
   | id          | 84c23f4b942c44c38b9c42c5e517cd9a |
   | name        | swift                            |
   | type        | object-store                     |
   +-------------+----------------------------------+

3. To get details for a service, run this command:

   $ openstack service show SERVICE_TYPE|SERVICE_NAME|SERVICE_ID

   For example:

   $ openstack service show object-store
   +-------------+----------------------------------+
   | Field       | Value                            |
   +-------------+----------------------------------+
   | description | object store service             |
   | enabled     | True                             |
   | id          | 84c23f4b942c44c38b9c42c5e517cd9a |
   | name        | swift                            |
   | type        | object-store                     |
   +-------------+----------------------------------+

Create an endpoint

1. Once a service is created, register it at an endpoint:

   $ openstack endpoint create nova public http://example.com/compute/v2.1
   +--------------+----------------------------------+
   | Field        | Value                            |
   +--------------+----------------------------------+
   | enabled      | True                             |
   | id           | c219aa779e90403eb4a78cf0aa7d38b1 |
   | interface    | public                           |
   | region       | None                             |
   | region_id    | None                             |
   | service_id   | 0f5da035b8e94629bf35e7ec1703a8eb |
   | service_name | nova                             |
   | service_type | compute                          |
   | url          | http://example.com/compute/v2.1  |
   +--------------+----------------------------------+

Delete a service

To delete a specified service, specify its ID.

$ openstack service delete SERVICE_TYPE|SERVICE_NAME|SERVICE_ID

For example:

$ openstack service delete object-store

Service users

To authenticate users against the Identity service, you must create a
service user for each OpenStack service. For example, create a service
user for the Compute, Block Storage, and Networking services.

To configure the OpenStack services with service users, create a
project for all services and create users for each service. Assign the
admin role to each service user and project pair. This role enables
users to validate tokens and authenticate and authorize other user
requests.

Create service users

1. Create a project for the service users. Typically, this project
   is named service, but choose any name you like:

   $ openstack project create service --domain default
   +-------------+----------------------------------+
   | Field       | Value                            |
   +-------------+----------------------------------+
   | description | None                             |
   | domain_id   | e601210181f54843b51b3edff41d4980 |
   | enabled     | True                             |
   | id          | 3e9f3f5399624b2db548d7f871bd5322 |
   | is_domain   | False                            |
   | name        | service                          |
   | parent_id   | e601210181f54843b51b3edff41d4980 |
   +-------------+----------------------------------+

2. Create service users for the relevant services for your
   deployment. For example:

   $ openstack user create nova --password Sekr3tPass
   +---------------------+----------------------------------+
   | Field               | Value                            |
   +---------------------+----------------------------------+
   | domain_id           | default                          |
   | enabled             | True                             |
   | id                  | 95ec3e1d5dd747f5a512d261731d29c7 |
   | name                | nova                             |
   | options             | {}                               |
   | password_expires_at | None                             |
   +---------------------+----------------------------------+

3. Assign the admin role to the user-project pair.

   $ openstack role add --project service --user nova admin
   +-------+----------------------------------+
   | Field | Value                            |
   +-------+----------------------------------+
   | id    | 233109e756c1465292f31e7662b429b1 |
   | name  | admin                            |
   +-------+----------------------------------+

Configuring service tokens

A lot of operations in OpenStack require communication between
multiple services on behalf of the user. For example, the Image service
storing the user’s images in the Object Storage service. If the image is
significantly large, the operation might fail due to the user’s token
having expired during upload.

In the above scenarios, the Image service will attach both the user’s
token and its own token (called the service token), as per the diagram
below.

+----------------+
|      User      |
+-------+--------+
        | Access Image Data Request
        | X-AUTH-TOKEN: <end user token>
        |
+-------v---------+
|     Glance      |
+-------+---------+
        | Access Image Data Request
        | X-AUTH-TOKEN: <original end user token>
        | X-SERVICE-TOKEN: <glance service user token>
        |
+-------v---------+
|      Swift      |
+-----------------+

When a service receives a call from another service, it validates
that the token has the appropriate roles for a service user. This is
configured in each individual service configuration, under the section
[keystone_authtoken].

If the service token is valid, the operation will be allowed even if
the user’s token has expired.

The service_token_roles option is the list of roles that
the service token must contain to be a valid service token. In the
previous steps, we have assigned the admin role to service users, so set the option
to that and set service_token_roles_required to
true.

[keystone_authtoken]
service_token_roles = admin
service_token_roles_required = true

For more information regarding service tokens, please see the
keystonemiddleware release
notes.