Each controller service needs to be modified so that it can be detached from
the controller role and deployed independently. This includes not only the
supporting services in Fuel, such as Galera and RabbitMQ, but potentially
all OpenStack services. For the scope of this spec, only Keystone and Horizon
are covered.

Corosync/Pacemaker/HAProxy will be fragmented per-role if any of the following
tasks are on separate roles:
* OpenStack services
* RabbitMQ
* Galera

A recommended deployment consists of 3 nodes to a custom role for full HA.

This feature will modify existing tasks and their dependencies, but does not
introduce new deployable roles. Those will only be possible through custom
roles defined by a deployer, usually via a Fuel Plugin.

Another goal of this spec is to deliver a set of examples and tools to enable a
plugin developer to create his or her own custom roles and split up the tasks
as desired, but ensure that all requirements for a complete deployment are met.

Testing will be unorthodox because of its deployer-driven customization focus.
It will be necessary to define a custom role and task to represent each (or a
group of) separated controller service(s). This will likely be in the form of a
custom Fuel plugin for testing. This deployment schema will require new logic
in fuel-qa to generate the role(s) and task(s) to deploy.

Manual functional testing of custom roles will be conducted

Separating DB/RabbitMQ/Horizon/Keystone from Controller role will
be covered with regression testing - mainly with fuel-qa automation tests
and manual checks of base cases and some corner cases like failover

System tests will be augmented to cover testing of custom roles deployment

OSTF will not be extended to cover deployment of services on separate nodes

Must be able to deploy a custom role with database task. All components
dependent on the database will connect to it via a database VIP on management
network.
Must be able to deploy a custom role with keystone task. All components
dependent on Keystone will connect to it via a keystone service_endpoint VIP on
management network.
Must be able to deploy a custom role with rabbitmq task. All components
dependent on RabbitMQ will connect to each as a list of nodes with rabbitmq
role.
Must be able to deploy controller role without keystone, database, or
rabbitmq task. All roles dependent on these tasks must be able to consume a
field in hiera for these endpoints.
Should have backward compatibility. In the absence of custom defined
rabbitmq_nodes, database_endpoint, keystone_service_endpoint, use
primary_controller IP or management_vip as before in 6.1.
Should create databases from OpenStack service tasks(nova, neutron, glance,
etc), not from database task.
Should create keystone users/endpoints from OpenStack service tasks(nova,
neutron, glance, etc), not from keystone task.
Custom tests should be developed to create controller_minus_$SERVICE and
$SERVICE custom roles to ensure granular deployment passes

New notes in Fuel Developer docs will be necessary to show an example of how to
create a plugin that creates a customized controller role. For example, any
role containing heat, neutron, Galera or RabbitMQ task also requires corosync.
Similarly, any role containing an OpenStack service or Galera requires a VIP.