Hi,
If I am not mistaken Mistral team listed Live migration as a potential use case for workflow engine. There is no much details though. https://wiki.openstack.org/wiki/Mistral#Live_migration As I know Mistral plan to implement generic event handling mechanism when one can bind any kind of workflow with external event triggered by Ceilometer or other monitoring system. This bound workflow can actually define live migration logic. Thanks Georgy On Thu, Feb 20, 2014 at 3:04 PM, Sean Dague <s...@dague.net> wrote: > On 02/20/2014 05:32 PM, Russell Bryant wrote: > > On 02/20/2014 05:05 PM, Costantino, Leandro I wrote: > >> Hi, > >> > >> Would like to know if there's any interest on having 'automatic > >> evacuation' feature when a compute node goes down. > >> I found 3 bps related to this topic: > >> [1] Adding a periodic task and using ServiceGroup API for > >> compute-node status > >> [2] Using ceilometer to trigger the evacuate api. > >> [3] Include some kind of H/A plugin by using a 'resource > >> optimization service' > >> > >> Most of those BP's have comments like 'this logic should not reside in > >> nova', so that's > >> why i am asking what should be the best approach to have something like > >> that. > >> > >> Should this be ignored, and just rely on external monitoring tools to > >> trigger the evacuation? > >> There are complex scenarios that require lot of logic that won't fit > >> into nova nor any other OS component. (For instance: sometimes it will > >> be faster to reboot the node or compute-nova than starting the > >> evacuation, but if it fail X times then trigger an evacuation, etc ) > >> > >> Any thought/comment// about this? > >> > >> Regards > >> Leandro > >> > >> [1] > https://blueprints.launchpad.net/nova/+spec/vm-auto-ha-when-host-broken > >> [2] > >> > https://blueprints.launchpad.net/nova/+spec/evacuate-instance-automatically > >> [3] > >> > https://blueprints.launchpad.net/nova/+spec/resource-optimization-service > > > > My opinion is that I would like to see this logic done outside of Nova. > > Right now Nova is the only service that really understands the compute > topology of hosts, though it's understanding of liveness is really not > sufficient to handle this kind of HA thing anyway. > > I think that's the real problem to solve. How to provide notifications > to somewhere outside of Nova on host death. And the question is, should > Nova be involved in just that part, keeping track of node liveness and > signaling up for someone else to deal with it? Honestly that part I'm > more on the fence about. Because putting another service in place to > just handle that monitoring seems overkill. > > I 100% agree that all the policy, reacting, logic for this should be > outside of Nova. Be it Heat or somewhere else. > > -Sean > > -- > Sean Dague > Samsung Research America > s...@dague.net / sean.da...@samsung.com > http://dague.net > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
