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

Eoghan Glynn eglynn at redhat.com
Fri Nov 23 12:17:38 UTC 2012


> I've outlined a variety of proposals for solving this problem using
> the existing infrastructure. There's not a large departure needed
> from where we are today.
> 
> In a nutshell, for lifecycle/metering purposes:
> 1. The existing notifiers are sufficient (they don't have to use
> AMQP)

Right, they don't.

> 2. The notification event should be structured with optional
> components and versioned accordingly.

OK.

> 3. The ceilometer worker pulls in much of the nova common rpc
> baggage, which is unnecessary (notifications are not rpc calls).
> Look at the StackTach worker for an example of something lean and
> mean.

That's a fair point, but orthogonal to the question of relying
entirely on notifications.

> 4. The existing usage notifications for bandwidth and state seem fine
> (I haven't heard objection use-cases). Any exceptions I've heard
> have been instrumentation or user-space based.

OK, by the notifications for bandwidth, do you mean the info extracted
via ComputeDriver.get_all_bw_counters()?

I may have misunderstood what's going on there, but that seemed quite
unsuitable to me as it currently exists.

Basically the problems are:

1. this is only currently supported for the xenapi driver (libvirt
   raises NotImplementedError).

2. the bandwidth stats are cached in the DB then retrieved again before
   being reported, so the mechanism is quite heavyweight.

3. the trigger for reporting the bandwidth are non-periodic instance
   lifecycle events like an update/resize/rebuild, or the low-frequency
   instance auditing (runs at most once an hour).

None of these issues are necessarily un-fixable, but I don't think
the mechanism is suitable for use out of the box.

Of course I'm open to correction if I mis-read the above issues in
nova, or if you had a different bandwidth notification mechanism
in mind.

> 5. There is a hook in the virt layer for getting info out. We could
> easily extend this to include optional drivers from ceilometer for
> customer specific needs.

Just to clarify, is that hook the get_all_bw_counters() driver API?

Cheers,
Eoghan



More information about the OpenStack-dev mailing list