4.2 Setting up Services

Before you can deploy OpenStack services, you need to enable the services you want to deploy, and then configure the services by setting passwords and properties.

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.7, “Preparing a Separate 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, Ceilometer, and Aodh services, and the Ceph component.
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.
The minimum OpenStack services you need to enable to operate a cloud are Glance, Keystone, Neutron and Nova.
Set 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.
The recommended way to set passwords is with the kollacli password init command, as this generates random strong passwords. It also ensures that all the required passwords for OpenStack services are set.
```
$ kollacli password init
```
If you prefer to have control over the passwords used, you can configured the passwords individually. See Section 4.6.2, “Configuring OpenStack Service Users and Passwords”.
If you do not set all the required passwords for OpenStack services, the deployment will fail. The kollacli password init command does not set the password to use for the Docker registry. This must be set separately, see Section 4.3, “Setting up the Docker Registry”.
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.9.1, “Configuring VLAN Networks” and Section 4.13, “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.5, “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:
kolla_internal_vip_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.
By default, this address is used to populate part of each OpenStack service's internal, admin, and public endpoint URL in Keystone. If you prefer, you can configure a separate address on a public network for the public endpoint URLs, configure fully qualified DNS names for the endpoint URLs, or manually configure the endpoint URLs for individual services. See Section 4.6.1, “Configuring OpenStack Service Endpoints” for details.
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 separate 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) 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. This interface must be available on all network nodes, and, if you are using Distributed Virtual Routing (DVR), on all compute nodes.
keepalived_virtual_router_id
The virtual router ID used by Keepalived to manage the virtual IP address. The default ID is 51. The ID is an integer between 0 and 255.
Only change this property if you have multiple OpenStack deployments on the same management/API network or an external instance of Keepalived on this network. Each deployment must have a unique virtual router ID.

If the nodes have differing network interface names, use group and host properties to set different interface names, see Section 4.5, “Setting Properties for Groups or Hosts”.