[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