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? 

Well we already have a separate polling daemon, the ceilo compute
agent.

Not sure what you mean exactly by "openstack-style" in this context.

Currently we use the common periodic task support to trigger the
polling cycle, but as you point out in another thread, this only
offers weak timing guarantees so may need to be revisited (e.g. to
allow high-priority time-sensitive tasks to be distinguished, as
you've suggested).
  

> If yes, possibly that can be in nova/glance also?

Do you mean, will ceilo poll glance in the same way as it does nova?

Currently glance is polled by ceilo for image existence via the public
glance API, so this doesn't need to be co-located is the same way that
the ceilo compute agent needs to be deployed to each compute node.
Instead the glance polling is handled from the ceilo central agent.


> 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?

Do you mean, if we harden the common period task support these
improvements should be used across the board not just in ceilo?

Absolutely!

Cheers,
Eoghan