Open Stack

I'm partial to #3 on the basis that it would encourage us to expose more useful information to the world. I don't think that would mean Ceiliometer is leaking into Nova, we're just exposing data that consumers are asking for.

I might be missing something silly, but why does Nova need to know where Ceiliometer's message bus is? Why can't Ceiliometer just listen on the queue wherever Nova, Glance, Cinder, etc are already producing notifications?


On Nov 14, 2012, at 9:28 AM, Eoghan Glynn wrote:

> 
> Folks,
> 
> TL;DR: soliciting feedback on the best (most stable/supportable)
> approach for ceilometer to interact with nova going forward.
> 
> Currently ceilo both consumes notifications from nova (instance
> lifecycle events & the like) and also periodically polls libvirt to
> extract more detailed info. This latter mechanism uses internal nova
> classes, so we want to move towards a model that is more stable and
> supportable into the future.
> 
> We are also currently limited to libvirt, so it would make sense to
> move towards a more hypervisor-agnostic position, or at least to
> provide wider support.
> 
> Now, there are at least 4 different approaches that could be followed,
> each with its own advantages and disadvantages, so I just wanted to
> call these out so to solicit some feedback and guidance from the nova
> domain experts ...
> 
> 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
>   -  the additional nova-api-->nova-compute RPC call would add lag
>      and impact timeliness for metrics gathering
> 
> 
> 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.
> 
>   +/- as for #1, but also removes the lag involved in an additional
>       hop between nova services
>   -   calling RPC directly would expose ceilo to a much less stable
>       (i.e. rapidly rev'd) API than would be the case for #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
>   - requires message bus usage, probably inappropriate for time-
>     sensitive measurements feeding into near-realtime metrics.
> 
> 
> 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
> 
> 
> So the question is how the nova domain experts see these options sizing
> up?
> 
> Personally I'm liking option #2, aside from a lingering concern about
> how rapidly RPC versioning is rev'd (which suggests the more sedate
> pace of API versioning would be easier to consume). Also some statement
> on whether RPC is envisaged as being externally-callable would be good.
> 
> Thoughts/feedback most welcome ...
> 
> Thanks,
> Eoghan
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev