Browse Source

Create ansible roles for cloud operator actions

The cli has traditionally been the only supported interface for
deploying tripleo. This however has lead to multiple implementations of
roles to perform the various tripleo actions. We should establish a
small supported set of ansible roles, modules and plugins that can be
used when writing automation around TripleO deployments.

Change-Id: I8ac853b78f57661f53f77cb185806461d7f029f2
changes/33/693933/7
Alex Schultz 2 years ago
parent
commit
9b45cd3d64
  1. 331
      specs/ussuri/tripleo-operator-ansible.rst

331
specs/ussuri/tripleo-operator-ansible.rst

@ -0,0 +1,331 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
=============================================================================
tripleo-operator-ansible - Ansible roles and modules to interact with TripleO
=============================================================================
https://blueprints.launchpad.net/tripleo/+spec/tripleo-operator-ansible
As an operator of a TripleO deployment, I would like to be able to comsume
supported ansible roles and modules that let me perform TripleO related
actions in my automation.
Problem Description
===================
The existing tripleo-ansible_ repository currently contains roles, plugins
and modules that are consumed by TripleO to perform the actual deployments and
configurations. As these are internal implementations to TripleO, we would not
want operators consuming these directly. The tripleo-ansible_ repository is
also branched which means that the contents within the repo and packaging
are specific to a singular release. This spec propose that we create a new
repository targeted for external automation for any supported version.
Currently Operators do not have a set of official ansible roles and modules
that can be used to deploy and manage TripleO environments. For folks who wish
to manage their TripleO environments in an automated fashion, we have seen
multiple folks implement the same roles to manage TripleO. e.g.
tripleo-quickstart_, tripleo-quickstart-extras_, infrared_, tripleo-lab_.
* TripleO should provide a set of ansible roles and modules that can be used
by the end user to deploy and manage an Undercloud and Overcloud.
* TripleO should provide a set of ansible roles and modules that can be used
to perform scaling actions.
* TripleO should provide a set of ansible roles and modules that can be used
to perform update and upgrade actions.
.. _tripleo-ansible: https://opendev.org/openstack/tripleo-ansible
.. _infrared: https://github.com/redhat-openstack/infrared
.. _tripleo-quickstart: https://opendev.org/openstack/tripleo-quickstart
.. _tripleo-quickstart-extras: https://opendev.org/openstack/tripleo-quickstart-extras
.. _tripleo-lab: https://github.com/cjeanner/tripleo-lab
Proposed Change
===============
Overview
--------
TripleO should create a new repository where ansible roles, plugins and
modules that wrap TripleO actions can be stored. This repository should be
branchless so that the roles can be used with any currently supported version
of TripleO. The goal is to only provide automation for TripleO actions and not
necessarily other cloud related actions. The roles in this new repository
should only be targeted to providing an automation interface for the existing
`tripleoclient commands`_. The repository may provide basic setups actions such
as implementing a wrapper around tripleo-repos_. The roles contained in this
repository should not implement additional day 2 cloud related operations such
as creating servers, networks or other resources on the deployed Overcloud.
This new repository should be able to be packaged and distributed via an RPM
as well as being able to be published to `Ansible Galaxy`_. The structure
of this new repository should be Ansible collections_ compatible.
The target audience of the new repository would be end users (operators,
developers, etc) who want to write automation around TripleO. The new
repository and roles would be our officially supported automation artifacts.
One way to describe this would be like providing Puppet modules for a given
peice of software so that it can be consumed by users who use Puppet. The
existing CLI will continue to function for users who do not want to use
Ansible to automate TripleO deployments or who wish to continue to use the CLI
by hand. The roles are not a replacement for the CLI, but only provide an
official set of roles for people who use Ansible.
The integration point for Ansible users would be the roles provided via
tripleo-operator-ansible. We would expect users to perform actions by
including our provided roles.
An example playbook for a user could be:
.. code-block:: yaml
- hosts: undercloud
gather_facts: true
tasks:
- include_role:
role: tripleo_undercloud
tasks_from: install
vars:
tripleo_undercloud_configuration:
DEFAULT:
undercloud_debug: True
local_ip: 192.168.50.1/24
- name: Copy nodes.json
copy:
src: /home/myuser/my-environment-nodes.json
dest: /home/stack/nodes.json
- include_role:
role: tripleo_baremetal
tasks_from: introspection
vars:
tripleo_baremetal_nodes_file: /home/stack/nodes.json
tripleo_baremetal_introspection_provide: True
tripleo_baremetal_introspection_all_managable: True
- include_role:
role: tripleo_overcloud
tasks_from: deploy
vars:
tripleo_overcloud_environment_files:
- network_isolation.yaml
- ceph_storage.yaml
tripleo_overcloud_roles:
- Controller
- Networker
- Compute
- CephStorage
The internals of these roles could possibly proceed in two different paths:
* Implement simple wrappers around the invocation of the actual TripleO
commands using execs, shell or commands. This path will likely be the fastest
path to have an initial implementation.
.. code-block:: yaml
- name: Install undercloud
command: "openstack undercloud install {{ tripleo_undercloud_install_options }}"
chdir: "{{ tripleo_undercloud_install_directory }}"
* Implement a python wrapper to call into the provided tripleoclient classes.
This path may be a longer term goal as we may be able to provide better
testing by using modules.
.. code-block:: python
#!/usr/bin/python
# import the python-tripleoclient
# undercloud cli
from tripleoclient.v1 import undercloud
import sys
import json
import os
import shlex
# See the following for details
# https://opendev.org/openstack/python-tripleoclient/src/branch/
# master/tripleoclient/v1/undercloud.py
# setup the osc command
class Arg:
verbose_level = 4
# instantiate the
u = undercloud.InstallUndercloud('tripleo', Arg())
# prog_name = 'openstack undercloud install'
tripleo_args = u.get_parser('openstack undercloud install')
# read the argument string from the arguments file
args_file = sys.argv[1]
args_data = file(args_file).read()
# For this module, we're going to do key=value style arguments.
arguments = shlex.split(args_data)
for arg in arguments:
# ignore any arguments without an equals in it
if "=" in arg:
(key, value) = arg.split("=")
# if setting the time, the key 'time'
# will contain the value we want to set the time to
if key == "dry_run":
if value == "True":
tripleo_args.dry_run = True
else:
tripleo_args.dry_run = False
tripleo_args.force_stack_validations = False
tripleo_args.no_validations = True
tripleo_args.force_stack_update = False
tripleo_args.inflight = False
# execute the install via python-tripleoclient
rc = u.take_action(tripleo_args)
if rc != 0:
print(json.dumps({
"failed": True,
"msg": "failed tripleo undercloud install"
}))
sys.exit(1)
print(json.dumps({
"changed": True,
"msg": "SUCCESS"
}))
sys.exit(0)
.. code-block:: yaml
- name: Install undercloud
tripleo_undercloud:
install: true
foo: bar
These implementations will need to be evaluated to understand which works
best when attempting to support multiple versions of TripleO where options
may or may not be available. The example of this is where we supported one
cli parameter in versions >= Stein but not prior to this.
The goal is to have a complete set of roles to do basic deployments within
a single cycle. We should be able to itterate on the internals of the roles
once we have established basic set to prove out the concept. More complex
actions or other version support may follow on in later cycles.
.. _tripleoclient commands: https://docs.openstack.org/python-tripleoclient/latest/index.html
.. _tripleo-repos: https://opendev.org/openstack/tripleo-repos
.. _Ansible Galaxy: https://galaxy.ansible.com/
.. _collections: https://docs.ansible.com/ansible/latest/dev_guide/developing_collections.html
Alternatives
------------
* Do nothing and continue to have multiple tools re-implement the actions in
ansible roles.
* Pick a singular implementaion from the existing set and merge them together
within this existing tool. This however may include additional actions that
are outside of the scope of the TripleO management. This may also limit the
integration by others if established interfaces are too opinionated.
Security Impact
---------------
None.
Upgrade Impact
--------------
There should be no upgrade impact other than pulling in the upgrade related
actions into this repository.
Other End User Impact
---------------------
None.
Performance Impact
------------------
None.
Other Deployer Impact
---------------------
None.
Developer Impact
----------------
Developers will need to ensure the supported roles are updated if the cli
or other actions are updated with new options or patterns.
Implementation
==============
Assignee(s)
-----------
Primary assignee:
mwhahaha
Other contributors:
weshay
emilienm
cloudnull
Work Items
----------
The existing roles should be evaulated to see if they can be reused and pulled
into the new repository.
* Create new tripleo-operator-ansible
* Establish CI and testing framework for the new repository
* Evaulate and pull in existing roles if possible
* Initial implementation may only be a basic wrapper over the cli
* Update tripleo-quickstart to leverage the newly provided roles and remove
previously roles.
Dependencies
============
If there are OpenStack service related actions that need to occur, we may need
to investigate the inclusion of OpenStackSDK, shade or other upstream related
tools.
Testing
=======
The new repository should have molecule testing for any new role created.
Additionally once tripleo-quickstart begins to consume the roles we will need
to ensure that other deployment related CI jobs are included in the testing
matrix.
Documentation Impact
====================
The roles should be documented (perferrably automated) for the operators to
be able to consume these new roles.
References
==========
None.
Loading…
Cancel
Save