Open Stack

On Wed, 2018-08-15 at 13:08 -0600, Alex Schultz wrote:
> On Tue, Aug 14, 2018 at 11:51 AM, 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.
> > 
> 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-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/20180815/9b637a93/attachment.sig>