On Wed, Jul 12, 2017 at 2:04 AM, Giulio Fidente <gfide...@redhat.com> wrote:
> On 07/12/2017 01:53 AM, James Slagle wrote: > >> On Tue, Jul 11, 2017 at 5:53 PM, Steve Baker <sba...@redhat.com> wrote: >> >>> >>> <snip> > >> 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? >>> >> > interesting question, as long as we run playbooks from a filesystem, I > suppose users can make customizations without "changing" anything in > tripleo ... this is how we tested some of the ceph-ansible fixes! > > for upgrades we should maintain the tasks outside the templates do be able > to do that though, assuming we want users to customize the upgrade tasks I like this option too! Perhaps we could add a new task to a mistral workflow that uses this approach to store the info that was generated dynamically from Heat (e.g. inventory and extra-vars) somewhere (swift?) and then make it easy for the user to get this info and run the playbook manually. Kind of like a debug-on-error option with a dribble file [1] for the deployer. Assuming they get it working again, and we have idempotence, they should just be able to resume the deploy. John [1] https://ftp.gnu.org/old-gnu/Manuals/elisp-manual-20-2.5/html_chapter/elisp_18.html
__________________________________________________________________________ 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
