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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev