Open Stack

I wanted to provide an update on some next steps around config-download/Ansible
and TripleO. Now that we've completed transitioning to config-download by
default in Rocky, some might be wondering where we're going next.

1. Standalone roles.

The idea here is to refactor the ansible tasks lists into
standalone ansible roles. From the tripleo-heat-templates side, we then just
update the service templates to apply those roles (possibly with a specific
task file).

Since not all of the interfaces in tripleo-heat-templates are pure ansible
tasks lists (docker_config, puppet_config), there is some exploratory work here
to determine how we can use those inputs in both a standalone ansible role and
tripleo-heat-templates.

David Peacock sent out a POC of some inital work[1].

2. Standalone playbooks.

Similar to standalone roles, the idea here is to refactor some of the playbooks
into their own proper ansible project directories. These would probably be new
git repositories.

Again, since some of our playbooks are rendered by jinja2, there is some
exploratory work here to see how we can make these more re-usable and not as
tightly coupled with tripleo-heat-templates.

3. Native ansible tasks for the per-server deployments in
tripleo-heat-templates.

Presently we are using a generic ansible task(s) that acts as a shim around the
heat-config hooks for the per-server deployments. This is necessary for
backwards compatibility. Going forward, we want to take a closer look at how we
can use more native ansible tasks for these (e.g., os-net-config ansible
module).

This will improve our ansible playbook interfaces and make the playbooks more
friendly for manual interactions.

4. Ansible driven baremetal deployment

Dmitry Tantsur has indicated he's going to be looking at driving TripleO
baremetal provisioning with Ironic and ansible directly. This would remove
Heat+Nova from the baremetal provisioning workflows we currently use.

Obviously we have things to consider here such as backwards compatibility and
upgrades, but overall, I think this would be a great simplification to our
overall deployment workflow.

5. Other deployment architectures

There are various ongoing efforts continuing and spinning up related to
the:

- all-in-one/standalone installer[2]
- the zero footprint installer[3]
- split-controlplane[4]

I think config-download with ansible is going to drive a lot of these use
cases, particularly as it relates to edge deployments.

If any of this is an area of interest, please reach out. You can find contacts
on the provided links. There may be some upstream squads forming around some of
this work in the near future.

If you have other ideas about improvements/direction, please chime in.

[1] http://lists.openstack.org/pipermail/openstack-dev/2018-March/128887.html
[2] http://lists.openstack.org/pipermail/openstack-dev/2018-June/131135.html
[3] http://lists.openstack.org/pipermail/openstack-dev/2018-June/131192.html
[4] https://specs.openstack.org/openstack/tripleo-specs/specs/rocky/split-controlplane.html


-- 
-- James Slagle
--