Deployment of OpenStack Specifications
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 

11 KiB

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.

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:

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.
  • 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.

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.

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.