Re: [openstack-dev] [tripleo] ansible roles in tripleo
On Thu, 2018-08-23 at 10:42 -0400, Dan Prince wrote: > On Tue, Aug 14, 2018 at 1:53 PM Jill Rouleau 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 >
Re: [openstack-dev] [tripleo] ansible roles in tripleo
On Tue, Aug 14, 2018 at 1:53 PM Jill Rouleau 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-requ...@lists.openstack.org?subject:unsubscribe > 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:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] ansible roles in tripleo
On Wed, 2018-08-15 at 13:08 -0600, Alex Schultz wrote: > On Tue, Aug 14, 2018 at 11:51 AM, Jill Rouleau > 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
Re: [openstack-dev] [tripleo] ansible roles in tripleo
On Tue, Aug 14, 2018 at 11:51 AM, Jill Rouleau 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. Thanks, -Alex [0] http://git.openstack.org/cgit/openstack/tripleo-heat-templates/tree/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/13311 > 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:unsubscribe > 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:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] ansible roles in tripleo
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. 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/ 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
