Open Stack

Hi Steven et al.


2014-04-15 17:01 GMT+02:00 Steven Dake <sdake at redhat.com>:

>
>>  Qiming,
>
> 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).
>
> 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.
>
> Long term, HA, if desired, should be part of taskflow, though, because its
> a verb, and verbs don't belong as heat orchestrated resources.
>
> How we get from here to there is left as an exercise to the reader ;-)
>
> Regards
> -steve
>
>

>From my POV, I can consider that the HA feature would be something like
AutoScaling in Heat, meaning it would involve multiple stakeholders :
 - Ceilometer for aggregating metrics from hosts and raising an Alarm which
will trigger a WebHook corresponding to the faulty resource
 - Heat for declaring all HA policies within a template and creating
appropriate Ceilometer Alarms
 - the service behind the Webhook for executing the remediation actions
(Heat) which would call the appropriate services (eg. Nova)
 - eg. Nova to perform live migrations of the instances if possible, or
evacuate

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.

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...

-Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140415/91c169e9/attachment.html>