Open Stack

Brian, I think for your " Why can't Ceiliometer just listen on the queue wherever Nova, Glance, Cinder, etc are already  producing notifications", it's mainly because sometimes ceilometer need polling data with some interval like 1 minutes, like instance's CPU utilization. IMHO notification is mostly appropriate for event publish. Of course, we can wrap the notification mechanism to be configurable periodic notification.

Eoghan, I think the issue for option #4 apply to #3 also, right? Even with option #3, a loaded nova compute service may fall behind the periodic task. After all, usage stats always need periodic task. 

So I'm to #4, and with followed changes:
a) nova, cinder or other project publish the raw data through ceilometer's rpc call (in fact, through configuration, it can be any rpc call provided by metering components). Of course, the raw data format should be well defined and documented.

b) ceilometer do the translation from raw data to metering information.

c) Ceilometer use nova API to configure nova's publish attribute, like what resources should be published, the frequency of the publish etc.

Thanks
--jyh

> -----Original Message-----
> From: Eoghan Glynn [mailto:eglynn at redhat.com]
> Sent: Thursday, November 15, 2012 5:56 AM
> To: Brian Waldon
> Cc: OpenStack Development Mailing List
> Subject: Re: [openstack-dev] [nova][ceilometer] model for ceilo/nova
> interaction going forward
> 
> 
> 
> ----- Original Message -----
> > 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?
> 
> Sure, but that's not so much the issue I had in mind.
> 
> Its more that nova would have to start becoming concerned with the
> semantics of stats that ceilometer currently interprets. For example,
> nova might need to know how to derive say CPU utilization from the
> cumulative CPU time samples reported by the hypervisor driver.
> 
> So, its not knowledge of the ceilo queues leaking into nova that I'd
> be concerned about, more leakage of ceilo logic.
> 
> Cheers,
> Eoghan
> 
> 
> >
> > 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
> >
> >
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev