Open Stack

> 
> We're talking specifically about values like disk I/O, CPU stats, etc. That data
> isn't generated as part of a notification, that's why we're having to poll for it.
> What we're looking for is a solution that doesn't involve ceilometer importing
> part of nova's code *in an unsupported way*, as it does now. Some of the
> options presented involve new network-based communication between the
> existing ceilometer agent and the compute agent (RPC or REST, in different
> directions). None of those is really optimal, because we don't want to burden
> the compute agent with lots of calls asking for stats, either for metering or for
> monitoring. I think the option the ceilometer team is favoring at the moment is
> making the hypervisor library in nova a public API, so we can use it without fear
> of the API changing in unannounced ways. That would let us keep the
> hypervisor polling in a separate daemon from the hypervisor management.
> There are details to work out about how such a separate library would be
> implemented.
> 

If we create a separate polling daemon in ceilometer, will it be openstack-style? If yes, possibly that can be in nova/glance also? Not sure if any other requirement for such daemon.
Of course, it's different that the ceilometer agent is simple, and can handle the daemon better, but I think that should apply to all, if we make the daemon implementation robust?

--jyh