Open Stack

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

My read was that the consensus cohered in the follow-up discussion
during the nova IRC meeting[1].

> Honestly, after looking at what parts of Nova code Ceilometer
> currently uses, that approach looks like an awfully big
> hammer. 

K, let's think about a less weighty hammer.

> AFAICT, Ceilometer currently does some pretty simple and
> generic querying of libvirt for CPU, disk and NIC information.

Yes, exactly. But we want to be able to do it in the non-libvirt
cases too. And all without copying in a rake of nova code.

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

Well the way ceilo does it now (just picking up the whatever version
of the nova is available) is turning out to be a real headache keeping
up with internal mods to nova - the ceilo trunk regularly breaks
because some change in nova-land has an unforeseen impact on ceilo
(which is understandable, seeing as this code was never intended to
externally consumable).

So to address that instability, are you suggesting we take a big ol'
copy of some version (say 2012.2) of the nova virt code, prune it down
to the bits we need, then dump that into the ceilo repo?

Is the virt code sufficiently isolated within nova to do that?
e.g. say some bit of the nova utils or config code changes, wouldn't
that potentially have a knock-on impact?

Is it OK that adding a new driver type in nova would require ceilo
to notice and pick this up & distill out the bits needed?

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

OK, there seemed to be a willingness for nova use it expressed in
that IRC discussion, but yeah I take your point that it's a relatively
small piece.

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

So IIUC the other notifications produced by nova are not really on
a fine-grained periodic basis, being either triggered by lifecycle
events (e.g. an instance is updated in some way) or else are very
infrequent (e.g. the instance audit logic runs at most hourly). 

But in any case, one concern with nova-compute emitting these data
as either notifications or else making direct calls into a ceilo-
provided library was that such a loaded service is likely to
run into timeliness issues.

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

There's been a fair amount of fuzziness around the distinction
between instrumentation and monitoring, but this falls into the
latter camp for me. Its not so much about the internal dynamics
of nova, as the user-visible behavior (e.g. is my instance running
hot or am I pushing loads of data through the network, as opposed
how long did that API call to update the instance take to service
end-to-end or how many connections are in that pool).

Cheers,
Eoghan

[1] http://eavesdrop.openstack.org/meetings/nova/2012/nova.2012-11-15-21.04.log.html
#topic ceilometer/nova interaction as discussed on the ML