Open Stack

On Wed, Nov 14 2012, Eoghan Glynn wrote:

> 1. Extend the existing os-server-diagnostics API extension to expose
>    any additional stats that ceilo needs.
>
>    +  would allow the ceilo compute agent to be scaled independently
>       of the nova-compute node (i.e. no need for a 1:1 correspondence)
>    -  the diagnostics returned are currently hypervisor-specific

Fixable.

>    -  the additional nova-api-->nova-compute RPC call would add lag
>       and impact timeliness for metrics gathering

Unfixable.

Seems that's not the preferred option after all.

> 2. Call the nova get_diagnostics RPC directly (as per the experimental
>    patch proposed by Yunhong Jiang https://review.openstack.org/15952),
>    or use a new RPC message specifically designed for this purpose.

Still a good idea, also imposes a perpetual reply/request, like #1.

> 3. Have nova itself emit metering messages directly onto the ceilo
>    message bus, encompassing both lifecycle events and usage stats,
>    to be picked up and persisted by the ceilo collector or other agent.
>
>    - leaks ceilo concerns into nova

I'd disagree if you do this using notifications. :)

But this option is exactly what we do currently with
ceilometer-compute-agent.
If we just move this code into nova (compute-agent + libvirt pollster),
we just move the maintenance problem away into nova, which is probably a
better option. But for publishing we'll require Ceilometer RPC code,
which is just oslo.rpc actually.

> 4. Invert control and have the nova compute service itself call into a
>    ceilo-provided API that abstracts the conduit used for publication
>    (could be via the message bus, or UDP, or a direct call to a CW API)
>
>    - a loaded nova compute service may fall behind in this periodic
>      task, especially if the reporting cadence is configured high

This downside is a problem for all options actually.

Main downside for this is, IMHO, that you do leaks ceilo concerns into
nova here, because you're likely to use a special RPC, or UDP, or
anything.

And actually, option #4 you describe is option #3 with multi-publisher
on. 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.


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?

-- 
Julien Danjou
;; Free Software hacker & freelance
;; http://julien.danjou.info
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121115/3fc0e432/attachment.pgp>