Role reusability spec

Spec proposing more abstraction for greater reusability of the OSA
infrastructure roles.

Change-Id: Icb58c483627a15239bb45d2dbc64909b8e045768
This commit is contained in:
Logan V 2017-09-10 16:53:31 -05:00
parent 9390857f84
commit 98b3d9fe18
2 changed files with 179 additions and 0 deletions

View File

@ -12,6 +12,15 @@ Spec Templates
specs/templates/*
Queens Specifications
-------------------
.. toctree::
:glob:
:maxdepth: 1
specs/queens/*
Pike Specifications
-------------------

View File

@ -0,0 +1,170 @@
Generalize Infrastructure Roles
###############################
:date: 2017-09-10 14:00
:tags: ansible, roles, mariadb, rabbitmq
Provide a synopsis as to why you are creating this spec/blueprint.
Include the URL of your launchpad blueprint:
* https://blueprints.launchpad.net/openstack-ansible/+spec/ansible-roles-reuse
Currently openstack-ansible is maintaining infrastructure roles that are used
to deploy general infrastructure services such as MariaDB and RabbitMQ, which
are applicable in non-OpenStack ansible environments also. With little to no
refactoring these roles can be used to deploy the services in other Ansible
managed environments also.
By maintaining robust, generalized service roles, they are more likely to be
consumed, improved, and maintained by other operators in the greater Ansible
community. This will benefit us by training us to keep a modular mindset when
building the roles, which leads to better maintainability and wider testing
for OSA consumers also.
In some cases we may wish to deprecate our openstack-ansible roles and consume
more generalized upstream alternatives.
Problem description
===================
In some of the roles (such as haproxy), we implement a very OSA specific
deployment with very little reusability or configurability for a typical
HAProxy deployer.
Other roles, such as Galera server, are fairly generalized and robust, but
carry the openstack-ansible-service_name naming scheme, making it less likely
for anyone NOT using openstack-ansible to use the role in their deployments.
pip_install is an example of a role that will require some minor refactoring to
generalize it. The role performs some very out of scope tasks, such as repo
management, which have nothing to do with installing pip. These features should
be moved to appropriately modularized roles (a general repo management role?),
so that pip_install is only doing the work it is meant to do.
Proposed change
===============
Examine the following roles to identify and refactor out of scope tasks and
orchestrate openstack-ansible specific configurations at the integrated repo
level. If the role is built properly it should offer the necessary service
configuration to be injected from the inventory and playbooks.
Roles to examine initially:
* openstack-ansible-pip_install
* openstack-ansible-lxc_hosts
* openstack-ansible-lxc_container_create
* openstack-ansible-haproxy_server
* openstack-ansible-memcached_server
* openstack-ansible-galera_server
* openstack-ansible-rabbitmq_server
* openstack-ansible-ceph_client
Once the work outlined above has progressed sufficiently, we should consider
renaming some of the roles to a more appropriate naming, ie.
openstack-ansible-galera_server becomes ansible-mariadb-cluster, etc.
Alternatives
------------
N/A
Playbook/Role impact
--------------------
The playbooks and especially inventory should eventually contain all of our
openstack-ansible specific configurations. The infrastructure roles themselves
should be generalized without an assumption or skew toward being consumed only
by openstack-ansible.
In some cases this is already implemented, but in other cases the role will
undergo significant changes or wholesale replacement to accomplish this.
Upgrade impact
--------------
Consumers of the roles will need to adjust to any major refactorings that take
place, including possible renaming of the git sources and role names.
Security impact
---------------
N/A
Performance impact
------------------
N/A
End user impact
---------------
N/A
Deployer impact
---------------
Deployers who work frequently with openstack-ansible will benefit from the
ability to use the same roles to deploy applicable services for other projects
they work on besides OSA.
Developer impact
----------------
It is possible that this could draw more developers to assist in maintaining
some of the roles. Cosmetic changes such as renaming may also help veteran
OSA developers take a more abstract approach when crafting changes to these
roles, which should make them more maintainable in the long run.
Dependencies
------------
N/A
Implementation
==============
Assignee(s)
-----------
Primary assignee:
Logan Vig (LP: loganv; IRC: logan-)
Work items
----------
* Examine the infrastructure roles for out of scope tasks or reusability
concerns. Address the issues by refactoring or replacing the role.
* Improve the role documentation if necessary with example playbooks
demonstrating ad-hoc usage of the role.
* Rename the role and repo to a globally namespaced ansible role such as
ansible-service-name.
Testing
=======
N/A
Documentation impact
====================
Improving and expanding the role documentation will be beneficial for
reusability also.
References
==========
* openstack-ansible 5/18 community meeting: http://eavesdrop.openstack.org/meetings/openstack_ansible_meeting/2017/openstack_ansible_meeting.2017-05-18-16.01.log.html#l-136