<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jul 12, 2017 at 2:04 AM, Giulio Fidente <span dir="ltr"><<a href="mailto:gfidente@redhat.com" target="_blank">gfidente@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 07/12/2017 01:53 AM, James Slagle wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On Tue, Jul 11, 2017 at 5:53 PM, Steve Baker <<a href="mailto:sbaker@redhat.com" target="_blank">sbaker@redhat.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
</blockquote></blockquote>
</span><span class="gmail-"><snip><br>
</span><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
What would be nice is when a heat->mistral->ansible upgrade step fails, the<br>
operator is given an ansible-playbook command to run which skips directly to<br>
the failing step. This would dramatically reduce the debug cycle and also<br>
make it possible for the operator to automate any required fixes over every<br>
host in a role. This would likely mean rendering out ansible config files,<br>
playbooks, (and roles?) to the operator's working directory. What happens to<br>
these rendered files after deployment is an open question. Delete them?<br>
Encourage the operator to track them in source control?<br>
</blockquote></blockquote>
<br></span>
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!<br>
<br>
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</blockquote><div><br></div><div>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. </div><div><br></div><div>  John</div><div><br></div><div>[1] <a href="https://ftp.gnu.org/old-gnu/Manuals/elisp-manual-20-2.5/html_chapter/elisp_18.html">https://ftp.gnu.org/old-gnu/Manuals/elisp-manual-20-2.5/html_chapter/elisp_18.html</a></div></div></div></div>