Open Stack

On 07/07/2017 07:50 PM, James Slagle wrote:
> I proposed a session for the PTG
> (https://etherpad.openstack.org/p/tripleo-ptg-queens) about forming a
> common plan and vision around Ansible in TripleO.
> 
> I think it's important however that we kick this discussion off more
> broadly before the PTG, so that we can hopefully have some agreement
> for deeper discussions and prototyping when we actually meet in
> person.
> 
> Right now, we have multiple uses of Ansible in TripleO:

having worked on one of the versions listed, I would like to add some
comments

> (0) tripleo-quickstart which follows the common and well accepted
> approach to bundling a set of Ansible playbooks/roles.

this approach does not consume config data from heat; I don't think it
fits in the same category of the others

> (1) Mistral calling Ansible. This is the approach used by
> tripleo-validations where Mistral directly executes ansible playbooks
> using a dynamic inventory. The inventory is constructed from the
> server related stack outputs of the overcloud stack.

this approach is actually very similar to (3), with the main difference
that ansible is executed only *after* the stack is complete to be able
to build the dynamic inventory; in fact the flow looks like this:

tripleoclient -> mistral -> heat -> tripleoclient -> mistral (<< heat)

we couldn't use this same approach for ceph-ansible because we needed
the workflow to be executed during a specific overcloud deployment step;
if we had migrated to splitstack already, it might have been possible
(not sure though, more about this later)

> (2) Ansible running playbooks against localhost triggered by the
> heat-config Ansible hook. This approach is used by
> tripleo-heat-templates for upgrade tasks and various tasks for
> deploying containers.

we couldn't use this approach either because we needed to run an
unmodified version of ceph-ansible and provide to it the list of role
hosts in one shot so that ceph-ansible could manage the task
dependencies and ordering by itself; running on localhost wouldn't fit

> (3) Mistral calling Heat calling Mistral calling Ansible. In this
> approach, we have Mistral resources in tripleo-heat-templates that are
> created as part of the overcloud stack and in turn, the created
> Mistral action executions run ansible. This has been prototyped with
> using ceph-ansible to install Ceph as part of the overcloud
> deployment, and some of the work has already landed. There are also
> proposed WIP patches using this approach to install Kubernetes.

as per my comment about (1), this allows for execution of the workflows
to happen *during* the stack creation (at one or multiple deployment steps)

workflow tasks are described on a per-service basis, within the heat
templates and executions have access to the existing roles
config_settings which we also use for puppet

it allows interleaving of the puppet/workflow steps, which is a feature
we use for ceph-ansible for example to configure the firewall on the
nodes (using the established puppet manifests) before ceph-ansible
starts; we run ceph-ansible unmodified and users can provide arbitrary
extra vars to ceph-ansible via a heat parameter; the flow looks like this:

tripleoclient -> mistral -> heat -> mistral

also note, the workflows *can* run ansible (like it happens for
ceph-ansible) but don't need to, workflows can use any mistral action
and even define custom ones

I have proposed a topic for the ptg to discuss the above, I am sure it
can be extended and improved but IMHO it provides for a compelling set
of features (all of which we wanted/use for ceph-ansible)

> There are also some ideas forming around pulling the Ansible playbooks
> and vars out of Heat so that they can be rerun (or run initially)
> independently from the Heat SoftwareDeployment delivery mechanism:
> 
> (4) https://review.openstack.org/#/c/454816/
> 
> (5) Another idea I'd like to prototype is a local tool that runs on
> the undercloud and pulls all of the SoftwareDeployment data out of
> Heat as the stack is being created and generates corresponding Ansible
> playbooks to apply those deployments. Once a given playbook is
> generated by the tool, the tool would signal back to Heat that the
> deployment is complete. Heat then creates the whole stack without
> actually applying a single deployment to an overcloud node. At that
> point, Ansible (or Mistral->Ansible for an API) would be used to do
> the actual deployment of the Overcloud with the Undercloud as the
> ansible runner.

this seems interesting to me; do I understand correctly that if we keep
understanding of the deployment steps in heat then the flow would look like:

tripleoclient -> loop(mistral -> heat)

if so I think we'd need to move (or duplicate) some understanding about
the deployment steps from heat into mistral (as opposed to the approach
in (3) which keeps all the understanding in heat); I am not sure if
having this information in two tools will help in the long term but I
guess it has to be weighted with its pros

[...]
> I recognize that saying "moving away from Heat" may be quite
> controversial. While it's not 100% the same discussion as what we are
> doing with Ansible, I think it is a big part of the discussion and if
> we want to continue with Heat as the primary orchestration tool in
> TripleO.

I think this is a key question for the conversation we'll have; the
approach in (3) is based on the idea that heat stays and keeps
understanding of what/when is happening in the templates; I think we are
testing use of heat for the deployment of the undercloud cloud with the
intent to reuse this understanding.
-- 
Giulio Fidente
GPG KEY: 08D733BA