Open Stack

> Angus Salkeld wrote:
>
> Another option:
> We implement a collector plugin in nova that gets configured in
> ceilometer.conf as the compute instrumentator.

So this plugin lives in the nova repo and then get loaded by the
ceilo compute agent?

Wouldn't we have to address the same kind of versioning issues?

i.e. ceilo would want to pick up a stable version of the nova plugin,
and the nova plugin would need to depend on a stable version of
whatever ceilo interface it uses to publish the measurements.

Cheers,
Eoghan

> Then ceilometer doesn't have to implement anything specific at all.
> We do still need a list_instances() but that's all.
> 
> I thought that we have support for this right now in ceilometer.
> https://github.com/openstack/ceilometer/blob/master/ceilometer/compute/manager.py
> 
> We just move the plugin to nova and use it.
> 
> - Fast (no rest or rpc)
> - ceilometer controls the sampling rate
> - no duplicate code
> - easier to add support for the other virt types in nova where
>    the code and knowledge is.
> 
> Angus
> 
> >
> >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)
> >
> >> You'd be right to be concerned that you'd need to implement that
> >> same code for other hypervisors, but here's the thing - the
> >> get_disks() and block_stats() methods in the libvirt virt driver
> >> aren't part of the virt driver abstraction. Other drivers neither
> >> implement them, nor do we have common data structures for the
> >> values
> >> they'd return. In other words, the abstraction layer with multiple
> >> implementations doesn't yet exist.
> >
> >Yeah, looking at the inconsistencies in the level of support for the
> >ComputeDriver.get_diagnostics() function, I was figuring we'd need
> >to
> >potentially live with the API used by ceilo not being universally
> >supported across all hypervisors initially (but it still would be
> >less limiting than a direct libvirt dependency).
> >
> >> You know what's weird? The get_disks() and block_stats() methods
> >> appear unused in Nova.
> >
> >Yeah, I think pretty much the same logic is re-implemented in
> >LibvirtDriver.get_diagnostics.get_io_devices() in the libvirt case
> >at least - not good!
> >
> >> > 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.
> >>
> >> If the data is purely for metering, the timeliness issue isn't a
> >> concern right?
> >
> >Less of an issue certainly for pure metering (longer period, less
> >sensitive to irregular cadence).
> >
> >> > 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.
> >
> >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.
> >
> >Cheers,
> >Eoghan
> >
> >_______________________________________________
> >OpenStack-dev mailing list
> >OpenStack-dev at lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>