Open Stack

Hi,

Le 2013-08-07 07:34, Robert Collins a écrit :
> On 7 August 2013 21:16, matt <matt at nycresistor.com> wrote:
>> That is certainly a potential problem.
>
> So I think we should separate out 'observed state' from 'intended state'.

This is interesting but the more I think of it the more I understand the 
initial choice of state 'reporting'.

As soon as you start adding the 'observed state' you'd need to add some 
kind of timestamp to make sure you're not relying on an 'old' observed 
state. Moreover, you'll need to make sure the state gets updated 
properly (sensible time frame) as you now guarantee the status' 
coherence in (near) real-time.

If a node goes down, the VM state is the best thing to use to know if 
you need to evacuate them to another node for instance. So, unless you 
come up with another state for this peculiar situation, you're stuck 
with 'active'. This is the desired state according to user request, not 
a real-time status report on what is actually running on the nodes.

I guess that (near) real-time updates would also have performance 
impacts as of the 'state updating' in a DB that's aimed at management.

Somehow, if you want to guarantee the information, you could check 
instance and node status, but still may need to come up with other 
checks to avoid corner cases ...

Ultimately, the one and best way to make sure your VM is up, is trying 
to 'ping' it in some way (all this points back to full monitoring). 
Looking at collectd or parameters from ceilometer may help here.

All this is how I understand it for now.

-- 
=================================================
Ahmed Rahal <arahal at iweb.com> / iWeb Technologies
Spécialiste de l'Architecture TI
/ IT Architecture Specialist
=================================================