<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<font face="Calibri" size="2"><span style="font-size:11pt;">
<div>Horizon also needs the retry option. It solves a major problem specified in this blueprint: <a href="https://blueprints.launchpad.net/horizon/+spec/relaunch-failed-stack"><font color="#0563C1"><u>https://blueprints.launchpad.net/horizon/+spec/relaunch-failed-stack</u></font></a></div>
<div> </div>
<div>Regards,</div>
<div>Nikunj</div>
<div> </div>
<div> </div>
<div>-----Original Message-----<br>
From: Patil, Anant (HP Converged Cloud R&D) <br>
Sent: Wednesday, January 14, 2015 5:54 PM<br>
To: openstack-dev@lists.openstack.org<br>
Subject: Re: [openstack-dev] [Heat] Precursor to Phase 1 Convergence</div>
<div> </div>
<div>On 09-Jan-15 19:19, Zane Bitter wrote:</div>
<div>> On 09/01/15 01:07, Angus Salkeld wrote:</div>
<div>>> I am not in favor of the --continue as an API. I'd suggest responding </div>
<div>>> to resource timeouts and if there is no response from the task, then </div>
<div>>> re-start (continue) the task.</div>
<div>> </div>
<div>> Yeah, I am not in favour of a new API either. In fact, I believe we </div>
<div>> already have this functionality: if you do another update with the </div>
<div>> same template and parameters then it will break the lock and continue </div>
<div>> the update if the engine running the previous update has failed. And </div>
<div>> when we switch over to convergence it will still do the Right Thing </div>
<div>> without any extra implementation effort.</div>
<div>> </div>
<div>> There is one improvement we can make to the API though: in Juno, Ton </div>
<div>> added a PATCH method to stack update such that you can reuse the </div>
<div>> existing parameters without specifying them again. We should extend </div>
<div>> this to the template also, so you wouldn't have to supply any data to </div>
<div>> get Heat to start another update with the same template and parameters.</div>
<div>> </div>
<div>> I'm not sure if there is a blueprint for this already; co-ordinate </div>
<div>> with Ton if you are planning to work on it.</div>
<div>> </div>
<div>> cheers,</div>
<div>> Zane.</div>
<div>> </div>
<div>> _______________________________________________</div>
<div>> OpenStack-dev mailing list</div>
<div>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a></div>
<div>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></div>
<div>> </div>
<div>IMHO, there are two different things here:</div>
<div> </div>
<div>1. Failures external to Heat engine (or out-of-band failures). A convenient way to issue a stack-update on a stack that fails due to out-of-band failures is needed. When a stack fails due to service unavailability or infrastructure issues, operators/admins
can fix those issues and then re-start the provisioning or tell users to restart.</div>
<div>Currently, it is done by issuing a stack-update on the failed stack. It will be convenient to have an option to the stack-update command to retry the stack operation without having to specify the templates and parameters + environment again. User shouldn't
need to supply any data again to start the update of failed stack.</div>
<div> </div>
<div>Folks working in Horizon would definitely need something like this.</div>
<div>Horizon UI need not save a local copy of template and parameter + environment supplied by user, but rely on Heat because Heat already has the data. It would be convenient for Horizon to issue a --retry for stack-create or stack-update when the stack fails
due to external problems that the operators/users fix.</div>
<div> </div>
<div>2. Internal failures (or Heat engine failing). Continuing a stack operation even after a Heat engine fails due to internal error. I think Vishnu is talking about this part. When an engine fails, other engines should be able to take up the task of provisioning
the stack without any user intervention. No new API or any option to stack-create or update is needed. Something like a periodic timer is needed to check if the engine provisioning a stack is up. If not, the lock is stolen and stack is restarted... may be by
again issuing stack-update with same template and parameters. This is like an interim solution to continuous observer...the stack timer would periodically check for stacks that are "stuck" because the engine failed and issue another update or something equivalent
to proceed with other Heat engines. Or as a first step, like Steve said, put the stack to FAILED state and let user initiate a stack-update (probably with the option specified 1).</div>
<div> </div>
<div>Please share your thoughts.</div>
<div> </div>
<div>- Anant</div>
<div> </div>
<div>__________________________________________________________________________</div>
<div>OpenStack Development Mailing List (not for usage questions)</div>
<div>Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a></div>
<div><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></div>
<div> </div>
</span></font>
</body>
</html>