4.2 Setting up Services

On the master node, log in as a user that is a member of the kolla group.

You add users to the kolla group as part of setting up a master node, see Section 3.6, “Preparing a Master Node”.

All of the following steps use the kollacli command, and you must be a member of the kolla group to use this command.

Enable the OpenStack services you want to deploy.

All OpenStack services are enabled by default, apart from the Swift object storage and the Ceilometer telemetry services.

You enable and disable services with the kollacli property set command:

$ kollacli property set enable_service_name yes|no

For example, to enable the Swift service and disable the Cinder service:

$ kollacli property set enable_swift yes
$ kollacli property set enable_cinder no

Many OpenStack services contain several components, and each component is deployed as a separate Docker container. When a service is enabled, all of the service components (known as subservices) are also enabled by default. If required, you can enable and disable subservices with the kollacli property set command, although normally you do not need to do this.

To see a list of the available services and their subservices, use the kollacli service list command. Use the kollacli property list command to see the properties for enabling and disabling services and subservices.

Configure the passwords for all services.

You only need to perform this step once.

Typically, when you deploy an OpenStack service, a database is created for the service and the credentials for the service admin user are registered with the Keystone service. You must set passwords for the database and the service admin user. Passwords for other OpenStack features might also be required.

You set passwords with the kollacli password set command:

$ kollacli password set password_name

For example, for the Cinder service set the following passwords:

$ kollacli password set cinder_database_password
$ kollacli password set cinder_keystone_password

You are prompted for a password, and to confirm the password. The password value is not displayed on screen. You might want to use a strong password generator to generate the passwords.

If you do not set passwords, the default password is used, which is "password". For security reasons, it is best to set passwords for all the password names listed in the following table, even if you do not deploy all the OpenStack services.

Password Name	Description
`ceilometer_database_password`	Database password for the Ceilometer service.
`ceilometer_keystone_password`	Password for the Ceilometer service user, named `ceilometer` by default.
`cinder_database_password`	Database password for the Cinder service.
`cinder_keystone_password`	Password for the Cinder service user, named `cinder` by default.
`database_password`	Root password for the MySQL database.
`glance_database_password`	Database password for the Glance service.
`glance_keystone_password`	Password for the Glance service user, named `glance` by default.
`heat_database_password`	Database password for the Heat service.
`heat_domain_admin_password`	Password for the Heat ‘stack-domain-admin’ user.
`heat_keystone_password`	Password for the Heat service user, named `heat` by default.
`horizon_database_password`	Database password for the Horizon service.
`keystone_admin_password`	Password for the Keystone `admin` user.
`keystone_database_password`	Database password for the Keystone service.
`murano_database_password`	Database password for the Murano service.
`murano_keystone_password`	Password for the Murano service user, named `murano` by default.
`neutron_database_password`	Database password for the Neutron service.
`neutron_keystone_password`	Password for the Neutron service user, named `neutron` by default.
`nova_database_password`	Database password for the Nova service.
`nova_keystone_password`	Password for the Nova service user, named `nova` by default
`rabbitmq_password`	Password for the RabbitMQ `guest` user.
`swift_keystone_password`	Password for the Swift service user, named `swift` by default.

Configure the deployment by setting properties.

You set properties for services with the kollacli property set command:

$ kollacli property set property_name property_value

Use the kollacli property list command to see a list of the available properties. Some properties are used in the configuration files for the OpenStack services when they are deployed. These properties usually contain the name of the service in the property name, for example names of the properties for the Glance image service start with "glance_".

For examples of setting properties for specific services, see Section 4.7.1, “Configuring VLAN Networks” and Section 4.10, “Setting up Ceilometer”.

When you set properties, they are global properties that can be applied to all hosts and OpenStack services in your deployment. However, to enable you to tune your deployment, you can also set properties that are specific to particular groups or individual hosts, see Section 4.4, “Setting Properties for Groups or Hosts”.

For the majority of the properties, the default property values are sufficient.

The only properties that you must set are the network settings for the deployment. Be sure to review the information in Section 3.3, “Host Network Requirements” before setting the following properties:

docker_registry

The host name or IP address, and the port number, of the server that runs your Docker registry, for example myregistry.example.com:5000.

kolla_external_address

The DNS name or IP address to be used in the public OpenStack API endpoints. By default, this property is set to the same value as kolla_internal_address.

For private cloud deployments, do not change the default setting (the kolla_internal_address is used).

For public cloud deployments, this is a DNS name that resolves to a public IP address. The OpenStack operator is responsible for mapping the public IP address to the kolla_internal_address, for example through a firewall or load balancer.

By default, this value is used to populate part of each OpenStack service's public_url in Keystone. But you can configure the address for individual services if you prefer.

kolla_internal_address

The IP address on the internal management/API network used to access OpenStack control services.

This is an unused IP address on the internal management/API network and is used by Keepalived as the virtual IP (VIP) address. Keepalived maps the VIP address to the real IP address of the controller node that runs the current active HAProxy.

By default, this value is used to populate part of each OpenStack service's private_url and admin_url in Keystone. But you can configure the address for individual services if you prefer.

network_interface

The name of the network interface (for example, em1) on all nodes which is connected to the internal management/API network.

By default, this interface is also used for the virtual machine and storage network traffic. If you set up seperate networks for this traffic, set the name of the network interface on each network by configuring the tunnel_interface (virtual machine network), and storage_interface (storage network) properties.

neutron_external_interface

The name of the network interface (for example, em2) on all network nodes which is connected to the external network where the neutron public network will be created. This interface should not have an IP address and should not be the same as the network_interface.

virtual_router_id

The virtual router ID used by Keepalived to manage the virtual IP address. The default ID is 51.

Only change this property if you have multiple OpenStack deployments on the same management/API network. Each deployment must have a unique virtual router ID.