<div dir="ltr">Hi Steven et al.<br><div class="gmail_extra"><br><br><div class="gmail_quote">2014-04-15 17:01 GMT+02:00 Steven Dake <span dir="ltr"><<a href="mailto:sdake@redhat.com" target="_blank">sdake@redhat.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
</blockquote></div></div>
Qiming,<br>
<br>
If you read my original post on this thread, it outlines the current heat-core thinking, which is to reduce the scope of this resource from the Heat resources since it describes a workflow rather then an orchestrated thing (a Noun).<br>

<br>
A good framework for HA already exists for HA in the HARestarter resource.  It incorporates HA escalation, which is a critical feature of any HA system.  The fundamental problem with HARestarter is that is in the wrong project.<br>

<br>
Long term, HA, if desired, should be part of taskflow, though, because its a verb, and verbs don't belong as heat orchestrated resources.<br>
<br>
How we get from here to there is left as an exercise to the reader ;-)<br>
<br>
Regards<br>
-steve<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div><br></div><div>From my POV, I can consider that the HA feature would be something like AutoScaling in Heat, meaning it would involve multiple stakeholders : </div>
<div> - Ceilometer for aggregating metrics from hosts and raising an Alarm which will trigger a WebHook corresponding to the faulty resource</div><div> - Heat for declaring all HA policies within a template and creating appropriate Ceilometer Alarms </div>
<div> - the service behind the Webhook for executing the remediation actions (Heat) which would call the appropriate services (eg. Nova)</div><div> - eg. Nova to perform live migrations of the instances if possible, or evacuate</div>
<div><br></div><div>I don't know if Taskflow would be necessary for doing the logic here, that's more likely a placement issue than a workflow issue, as it requires to schedule new resources but can only be made on a per-resource basis (Nova instances, Cinder volumes, etc.). Taskflow would here be helpful for having a all-or-one logic in case of the migration untl the scheduling would be holistic.</div>
<div><br></div><div>Of course, in a far far away galaxy, we could consider having one global Scheduler for placement decisions that Heat could query for live migrating resources, but I'm still dreaming...</div><div><br>
</div><div>-Sylvain</div></div></div></div>