Open Stack

Hi fellow Fuelers and Stackers,

I'm writing to you with an update on the project I am working on
regarding separating one or more services from a Fuel controller node.
The scope of this project is limited at this point to separation of
database, keystone, RabbitMQ, and horizon from the default controller.

Spec: https://github.com/stackforge/fuel-specs/blob/master/specs/7.0/separate-services.rst

The current implementation requires creation of two new roles:
controller_minus_service and service
While we are waiting for Role as a Plugin[0] feature to become ready,
we have a workaround to create roles via plugin postinstall[1]

The main objective of implementing this function is to enable a
deployer to move services off the controller. With respect to Fuel
Library, this means changing two things: tasks and hiera.

Skipping tasks is currently accomplished by defining new roles. There
is a high chance that this will be covered in Role as a Plugin feature
and we can retain the original "controller" role.

Hiera is used to override default parameters. For example, if I want
an external DB, I need to replace the metadata Fuel generates for nova
DB with a specified management_vip, db_name, db_user, db_password in
hiera for the nova hiera hash. That can't be accomplished right now
via an API call because plugins have no deployment hooks and can only
write in astute.yaml inside its own plugin hash. Instead, a Puppet
task should be run to take the plugin's metadata and create a new YAML
file in Hiera. I understand that it provides a huge learning curve for
a plugin developer to write a task and puppet file to enable
replacement of default features, but it's the only capability
available right now.

Once the proper values have been set in Hiera, the tasks will be more
flexible for selecting the appropriate endpoint for services. In this
example[2], if you set 'service_endpoint' in hiera, it gets used for
Keystone. If not, management_vip gets used.

The ultimate goal here is to allow any specific service to be deployed
on its own role or even externally from a single Fuel environment. It
could be used to enable multi-region deployments for distributed
scale.



I should mention we have a few setbacks that impact user experience on
Fuel Python side for this feature.

The first is OSTF would need to be trained to identify the new
location of these endpoints. Since hiera becomes the source of truth,
it should be queried for the proper endpoints and credentials. Without
OSTF support for this feature, a deployer or plugin developer could
not easily verify that the deployment was successful.

The second is the complexity of the task graph to create new roles. A
plugin developer would need to copy the task graph and manually create
a new role, group, and list of tasks for the customized roles. This is
a little unintuitive. It would be helpful if we could have the ability
in a plugin to "skip" a task to enable this feature. As an
alternative, a way to generate a task graph (in order to generate a
role), skipping $STEPS, would serve developers as well.

I already mentioned the API call from a plugin step as something that
isn't supported yet, so I won't repeat that item.

Thanks for reading my update on this project. I look forward to your
feedback and comments.

Best Regards,
Matthew Mosesohn

[0] https://blueprints.launchpad.net/fuel/+spec/role-as-a-plugin
[1] https://review.openstack.org/#/c/189262/
[2] https://github.com/stackforge/fuel-library/blob/master/deployment/puppet/osnailyfacter/modular/openstack-cinder/openstack-cinder.pp#L14