On Thu, 2018-08-23 at 10:42 -0400, Dan Prince wrote: > On Tue, Aug 14, 2018 at 1:53 PM Jill Rouleau <ji...@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-requ...@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-requ...@lists.openstack.org?subject:unsubsc > ribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
signature.asc
Description: This is a digitally signed message part
__________________________________________________________________________ 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