Open Stack

On 02/20/2014 06:04 PM, Sean Dague 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.

I think we agree.  I'm very interested in continuing to enhance Nova
to make sure that the thing outside of Nova has all of the APIs it
needs to get the job done.

-- 
Russell Bryant