Open Stack

On Fri, Nov 23, 2012 at 1:26 AM, Mark McLoughlin <markmc at redhat.com> wrote:

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

We've had conflicting messages on that point. When we applied for
incubation I understood the TC mandate for the project to be "measure
everything," and that has led to consideration of features like monitoring
and collecting data more frequently and in different ways than would be
necessary for just billing-related purposes. However, when changes related
to those features are proposed we've had some push-back because of scope
creep. Are you suggesting we should drop the monitoring work?

Doug


>
> Cheers,
> Mark.
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121126/f7e365f5/attachment.html>