[openstack-dev] [nova][ceilometer] model for ceilo/nova interaction going forward

Mark McLoughlin markmc at redhat.com
Fri Nov 23 06:26:49 UTC 2012


On Thu, 2012-11-22 at 16:32 -0500, Eoghan Glynn wrote:

> > I really don't see much issue with ceilometer just doing those few
> > things directly. The only private implementation assumption you'd be
> > making about the Nova libvirt driver is that the libvirt VM name is
> > the same as the instance name.
> 
> Well I was thinking we'd also need ComputeDriver.list_instances()
> at least (previously we pulled the instances for the compute node
> directly from the nova DB, now we query the nova-api, but neither
> solution is really optimal).
> 
> But just to confirm I understand the suggestion, by *direct* usage
> do you mean simply calling the currently installed nova virt code
> but at a level that is unlikely to change? (say by pushing some
> internals of the driver implementation into the driver API)

Nope, don't use any code - just have your own code for talking directly
to libvirt and other hypervisors.

(And for clarity - this is if ceilometer must do the polling directly. I
still think notifications are the way to go for now)

> > > 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).
> > 
> > Metering vs monitoring/instrumentation, not monitoring vs
> > instrumentation :)
> 
> I kinda see the split more as metering/monitoring vs instrumentation.

I don't see why. Timeliness is a concern for user-oriented monitoring
but not for metering.

Timeliness is the issue in this discussion.

So, they're clearly not the same thing for the purposes of this
discussion.

> Well, actually more like metering/user-oriented-monitoring vs 
> cloud-operator-oriented-monitoring/instrumentation.
> 
> Currently ceilo is aiming to at least address both metering and 
> user-oriented-monitoring, and possibly more in time.
> 
> > If we were just designing a solution for metering, would we go for
> > the notifications option?
> 
> Probably, but the scope of ceilo has widened a bit from pure
> metering.

Right. From a far remove, that looks like a mistake at this early stage.

As Sandy rightly says, if we just focused on metering, then the
conclusion is simple - improve the notifications infrastructure. If
Ceilometer focused on its original mission, forward progress would be
easier.

Cheers,
Mark.




More information about the OpenStack-dev mailing list