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

Eoghan Glynn eglynn at redhat.com
Thu Nov 15 11:31:22 UTC 2012


> And actually, option #4 you describe is option #3 with
> multi-publisher on.

Well, yes, if by 'on' you mean 'available in-process'.

> That means option #3 where the only requirement for the
> ceilometer-compute-agent (that would be moved into nova) is not
> oslo.rpc only, but various publisher provided by Ceilometer.

Exactly.

> So my final option would be #4 possibly described as:
> Rename ceilometer-compute-agent to nova-compute-metering and move it
> into nova with its pollster. Make it uses the multi-publisher code
> from Ceilometer so it's able to publish to a variety of destination
> (ceilometer-collector, CW…) according to configuration, and polling
> on interval that is configured via the publisher (as already
> discussed on the multi-publisher blueprints).
> 
>   + no request/reply (like option #1 and #2)
>   + maintained by nova, so doesn't break
>   + no need to have hypervizor specific code, possible to abstract
>   + no lag
>     option #1 do:
>      -> request to nova-api via REST
>         -> request to nova-compute via RPC
>         <- reply to nova-api via RPC
>      -> reply to ceilometer-agent-compute via REST
>     option #2 do:
>      -> request to nova-compute via RPC
>      <- reply to nova-api via RPC
>     option #3 do:
>      -> notification emitted by nova-compute via RPC
>       (on a time basis complicated to know and configure)
>     option #4 do:
>      -> something emitted by nova-compute via any media supported by
>         ceilo publishers
>       (on a time basis known by publishers configurations)
> 
> But is Nova ready to import (optionnaly) some ceilometer code?

So there appears to be some support from the ceilo side emerging
for option #4, and you've hit the nail on the head there with that
final question ...

Would the nova project be happy to accept:

 (a) the ceilo compute agent repackaged as nova-compute-metering

and,

 (b) the deployment of an additional daemon per compute node

It would be great if we could get some response to the above from
the nova "leadership" (loosely defined).

Just to muddy the waters further if I may, let me throw a further
option into the mix:

5. nova packages a consumable library layered over the hypervisor
   driver, that just exposes the diagnostics available from libvirt
   et al. The ceilo compute agent continues to exist under the ceilo
   umbrella, but talks to the hypervisor directly via this stable,
   versioned nova library.

   + no remote calls required from ceilo-->nova-{api|compute}
   - needs an independent versioning scheme
   - still stuck in the "implicit trust" model?

Thoughts?

Cheers,
Eoghan



More information about the OpenStack-dev mailing list