On Tue, Jul 11, 2017 at 5:53 PM, Steve Baker <sba...@redhat.com> wrote: > > > On Tue, Jul 11, 2017 at 3:37 AM, Lars Kellogg-Stedman <l...@redhat.com> > wrote: >> >> On Fri, Jul 7, 2017 at 1:50 PM, James Slagle <james.sla...@gmail.com> >> wrote: >>> >>> There are also some ideas forming around pulling the Ansible playbooks >>> >>> and vars out of Heat so that they can be rerun (or run initially) >>> independently from the Heat SoftwareDeployment delivery mechanism: >> >> >> I think the closer we can come to "the operator runs ansible-playbook to >> configure the overcloud" the better, but not because I think Ansible is >> inherently a great tool: rather, I think the many layers of indirection in >> our existing model make error reporting and diagnosis much more complicated >> that it needs to be. Combined with Puppet's "fail as late as possible" >> model, this means that (a) operators waste time waiting for a deployment >> that is ultimately going to fail but hasn't yet, and (b) when it does fail, >> they need relatively intimate knowledge of our deployment tools to backtrack >> through logs and find the root cause of the failure. >> >> If we can offer a deployment mode that reduces the number of layers >> between the operator and the actions being performed on the hosts I think we >> would win on both fronts: faster failures and reporting errors as close as >> possible to the actual problem will result in less frustration across the >> board. >> >> I do like Steve's suggestion of a split model where Heat is responsible >> for instantiating OpenStack resources while Ansible is used to perform host >> configuration tasks. Despite all the work done on Ansible's OpenStack >> modules, they feel inflexible and frustrating to work with when compared to >> Heat's state-aware, dependency ordered deployments. A solution that allows >> Heat to output configuration that can subsequently be consumed by Ansible -- >> either running manually or perhaps via Mistral for API-driven-deployments -- >> seems like an excellent goal. Using Heat as a "front-end" to the process >> means that we get to keep the parameter validation and documentation that is >> missing in Ansible, while still following the Unix philosophy of giving you >> enough rope to hang yourself if you really want it. > > > I think this nicely sums up what we should be aiming for, but I'd like to > elaborate on "either running manually or perhaps via Mistral for > API-driven-deployments". > > I think its important that we allow full support for both mistral-driven and > manually running playbooks. If there was no option to run ansible-playbook > directly then operators would miss one of the main benefits of using ansible > in the first place (which is leveraging their knowledge of inventory, > playbooks and roles to deploy things).
+1, I like this idea as well. If you have a few minutes could you summarize it here: https://etherpad.openstack.org/p/tripleo-ptg-queens-ansible I'm attempting to capture some of the common requirements from this thread for discussion at the ptg so we can consider them when choosing solution(s). > I'm thinking specifically about upgrade scenarios where a step fails. > Currently the only option is a manual diagnosis of the problem, manual > modification of state, then re-running the entire stack update to see if it > can get past the failing step. > > What would be nice is when a heat->mistral->ansible upgrade step fails, the > operator is given an ansible-playbook command to run which skips directly to > the failing step. This would dramatically reduce the debug cycle and also > make it possible for the operator to automate any required fixes over every > host in a role. This would likely mean rendering out ansible config files, > playbooks, (and roles?) to the operator's working directory. What happens to > these rendered files after deployment is an open question. Delete them? > Encourage the operator to track them in source control? -- -- James Slagle -- __________________________________________________________________________ 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
