Open Stack

On Tue, Aug 14, 2018 at 1:53 PM Jill Rouleau <jillr at redhat.com> wrote:
>
> Hey folks,
>
> Like Alex mentioned[0] earlier, we've created a bunch of ansible roles
> for tripleo specific bits.  The idea is to start putting some basic
> cookiecutter type things in them to get things started, then move some
> low-hanging fruit out of tripleo-heat-templates and into the appropriate
> roles.  For example, docker/services/keystone.yaml could have
> upgrade_tasks and fast_forward_upgrade_tasks moved into ansible-role-
> tripleo-keystone/tasks/(upgrade.yml|fast_forward_upgrade.yml), and the
> t-h-t updated to
> include_role: ansible-role-tripleo-keystone
>   tasks_from: upgrade.yml
> without having to modify any puppet or heat directives.
>
> This would let us define some patterns for implementing these tripleo
> roles during Stein while looking at how we can make use of ansible for
> things like core config.

I like the idea of consolidating the Ansible stuff and getting out of
the practice of inlining it into t-h-t. Especially the "core config"
which I take to mean moving away from Puppet and towards Ansible for
service level configuration. But presumably we are going to rely on
the upstream Openstack ansible-os_* projects to do the heavy config
lifting for us here though right? We won't have to do much on our side
to leverage that I hope other than translating old hiera to equivalent
settings for the config files to ensure some backwards comparability.

While I agree with the goals I do wonder if the shear number of git
repos we've created here is needed. Like with puppet-tripleo we were
able to combine a set of "small lightweight" manifests in a way to
wrap them around the upstream Puppet modules. Why not do the same with
ansible-role-tripleo? My concern is that we've created so many cookie
cutter repos with boilerplate code in them that ends up being much
heavier than the files which will actually reside in many of these
repos. This in addition to the extra review work and RPM packages we
need to constantly maintain.

Dan

>
> t-h-t and config-download will still drive the vast majority of playbook
> creation for now, but for new playbooks (such as for operations tasks)
> tripleo-ansible[1] would be our project directory.
>
> So in addition to the larger conversation about how deployers can start
> to standardize how we're all using ansible, I'd like to also have a
> tripleo-specific conversation at PTG on how we can break out some of our
> ansible that's currently embedded in t-h-t into more modular and
> flexible roles.
>
> Cheers,
> Jill
>
> [0] http://lists.openstack.org/pipermail/openstack-dev/2018-August/13311
> 9.html
> [1] https://git.openstack.org/cgit/openstack/tripleo-ansible/tree/__________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev