Open Stack

On Thu, 2018-08-23 at 10:42 -0400, Dan Prince wrote:
> 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.
> 

We'll hopefully be able to rely on the OSA roles for a lot of the
config, yes, but there will still be a fair bit of TripleO specific
stuff that will need to be handled, and that's what we plan to do in
these ansible-role-tripleo-* repos.  

> 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.
> 
In theory it should be roughly the same amount of commits/review work,
just a question of what repo they go to - service specific patches go to
the appropriate role and shared plugins, libs, etc go to the tripleo-
ansible project repo.

We want the roles to be modular rather than monolithic so only the roles
that are being used in a given environment need to be pulled in.  Also
by having them separated, they should be easier to parse and contribute
to.  Yes it's a higher number of repos that could be contributed to, but
when doing so a person won't have to mentally frontload how all of the
possible things work just to be able to add an upgrade task for service
$foo like it is today with t-h-t. 

Unless there's a different breakdown/layout you're thinking of beyond
"dump everything in one place"?

I'm interested in other options if we have some to reduce packaging or
maintenance overhead.  With other deployers I've done stable branches
checked out straight from git, but I doubt that would fly for
downstream.  We could push the roles to Ansible Galaxy but we would need
to think about how that would work for offline deploys and they still
need to be maintained there, it's just painting the problem a different
color.

- Jill


> 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/1
> > 3311
> > 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:unsub
> > scribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> ______________________________________________________________________
> ____
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubsc
> ribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180824/1f23f2fc/attachment.sig>