On Wed, 2018-08-15 at 13:08 -0600, Alex Schultz wrote: > On Tue, Aug 14, 2018 at 11:51 AM, 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. > > > Do we have any examples of what the upgrade.yml would be or what type > of variables (naming conventions or otherwise) which would need to be > handled as part of this transtion? I assume we may want to continue > passing in some variable to indicate the current deployment step. Is > there something along these lines that we will be proposing or need to > handle? We're already doing something similar with the > host_prep_tasks for the docker registry[0] but we have a set_fact > block to pass parameters in. I'm assuming we'll need to define > something similar.
The task file would look very much like the task as it exists in t-h-t today. For example if we took the FFU task out of docker/services.keystone.yaml and write that to ansible-role-tripleo- keystone/tasks/fast_forward_upgrade.yml, and update any necessary vars (like steps) to be role vars, like tripleo_keystone_step. Then docker/services.keystone.yaml could be updated like: fast_forward_upgrade_tasks: include_role: name: ansible-role-tripleo-keystone tasks_from: fast_forward_upgrade vars: tripleo_keystone_step: step|int - Jill > > Thanks, > -Alex > > [0] http://git.openstack.org/cgit/openstack/tripleo-heat-templates/tre > e/puppet/services/docker-registry.yaml#n54 > > > > > 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. > > > > 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
