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 -- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev