Open Stack

Sorry, I didn't manage to keep up with this thread as it happened and
I'm struggling to get a good handle on it now

Apparently there was some consensus in the thread around making the
nova.virt.driver interface and its implementations public and having
ceilometer consume that. I'm not really seeing that consensus reading
back.

Honestly, after looking at what parts of Nova code Ceilometer currently
uses, that approach looks like an awfully big hammer. AFAICT, Ceilometer
currently does some pretty simple and generic querying of libvirt for
CPU, disk and NIC information.

Even if we stick with this approach of having an agent that talks to
libvirt, is it really such a huge deal to have code in both Nova and
Ceilometer that does this?

Put it another way, if you made a standalone generic library for doing
just this piece, Nova probably wouldn't bother using it since so little
code is involved.

On Wed, 2012-11-14 at 16:55 -0500, Eoghan Glynn wrote:
> 
> ----- Original Message -----
> > I'm partial to #3 on the basis that it would encourage us to expose
> > more useful information to the world. I don't think that would mean
> > Ceiliometer is leaking into Nova, we're just exposing data that
> > consumers are asking for.
> > 
> > I might be missing something silly, but why does Nova need to know
> > where Ceiliometer's message bus is? Why can't Ceiliometer just
> > listen on the queue wherever Nova, Glance, Cinder, etc are already
> > producing notifications?
> 
> Sure, but that's not so much the issue I had in mind.
> 
> 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.

I think I've the same instinct as Brian on this - it doesn't seem
unreasonable for Nova to publish CPU/disk/NIC samples at the same
interval as other notifications.

What might be confusing this whole discussion is the discussion around
metering and instrumentation requirements. I think we should keep the
two concerns completely separate for now and plough ahead with what we
think makes sense for metering.

Cheers,
Mark.