Hi Aaron,

>>I've been playing with this a little bit;  is it too late to consider tracking
>>instead of 'cores'?  I'm not sure what it means for a particular core
>>ID to be 'healthy' - but I know what 'pmd24' not responding means.
>That's an interesting input. It's not late and all suggestions are most 
>I will try doing this in the next series.

I reworked and sent out V3 patch series here: 
In this series.
  -  Posix shared memory is removed.
  -  Logic has been changed to track threads as suggested in this thread. I 
have used hash maps for this.
>>Additionally, I'd suggest keeping words like 'healthy', and 'unhealthy'
>>out of it.  I'd basically just have this keepalive report things on the
>>thread you
>>*know* - last time it poked your status register (and you can also
>>track things like cpu utilization, etc, if you'd like).  Then let your
>>higher level thing that reads ceilometer make those "healthy"
>>determinations.  After all, sometimes 0% utilization is "healthy," and
>>sometimes it isn't.
>This makes sense. Infact It was the case in the beginning where only the core
>status was reported.
> Only recently I added this Datapath status row with the overall status. I 
> shall
>remove this and leave it to external monitoring apps to parse the data and
>decide it.

I have also removed this logic and now only the thread status is shown. It's 
now the job of monitoring framework to read the thread status and determine the 
health of the compute.

dev mailing list

Reply via email to