Open Stack

> > Its more that nova would have to start becoming concerned with the
> > semantics of stats that ceilometer currently interprets. For
> > example,
> > nova might need to know how to derive say CPU utilization from the
> > cumulative CPU time samples reported by the hypervisor driver.
> > 
> > So, its not knowledge of the ceilo queues leaking into nova that
> > I'd be concerned about, more leakage of ceilo logic.
> 
> Why does nova have to do that logic?  That can't be done on the
> notification consumption side?  If it can't be done on the
> consumption side, then I think it seems fair to put it in nova.

Yeah, the derived metric was probably a bad example, if the time
samples were actually timestamped on the nova side (e.g. at the
time of reading from libvirt as opposed to a random number of
millis later when the notification is sent) then the derivation
could indeed be done on the consumer side.

A better example would be the reporting cadence - nova would need
to know for example that something in the ceilo world was interested
in seeing CPU time every 60s, but only cared about instance existence
notifications every 300s.

> What are the performance differences with this approach vs options 1
> and 2?  If performance is a major concern, then an event based approach
> seems like it could be more efficient.  Or is there a reason a poll
> approach is needed?

Its not so much performance as timeliness - can we be sure that a
measure we need at 60s granularity will actually be taken every minute
on the dot, or with everything else going on within the nova-compute 
service might we end up with lots of random jitter on the measurement
points.

Cheers,
Eoghan