Open Stack

On Wed, Jul 12, 2017 at 2:04 AM, Giulio Fidente <gfidente at redhat.com> wrote:

> On 07/12/2017 01:53 AM, James Slagle wrote:
>
>> On Tue, Jul 11, 2017 at 5:53 PM, Steve Baker <sbaker at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170712/df18ddcf/attachment.html>