Open Stack

> -----Original Message-----
> From: Russell Bryant [mailto:rbryant at redhat.com]
> Sent: Thursday, November 15, 2012 3:23 AM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [nova][ceilometer] model for ceilo/nova
> interaction going forward
> 
> On 11/14/2012 12:28 PM, 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
> >    -  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
> 
> > 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.
> 
> I'm in favor of option #1.  This is primarily because I have been
> considering all rpc APIs to be private internal nova APIs.
> 
> The benefit of #2 over #1 appears to be a performance concern.  How
> sensitive to timing are these measurements?  Also, if they are very
> sensitive, it seems you'd be facing the same risk of problems due to
> delays using rpc directly, because the queues can certainly get backed
> up, so #2 doesn't help much.

I considered option #1 firstly and give up it in the end. My concern for option #1 is more on scalability and user experience. If all data collection metering go through nova api service, that will bring a lot of overload to it. Especially the overload is dynamic and can be potentially big, considering monitor and instrumentation requirement.

Per my understanding, the nova API will be used mainly by end-user to interact with openstack, so IMHO it's better to separate the metering flow with the user-request flow.

Although rpc api is private code to nova, is it possible to keep one api exceptionally maintained for metering? I think the API input should be simply some instance information.

As for the performance concern, I'm not sure if ceilometer is so sensitive to the rpc delay.

For invert control like option #3/#4, my concern is stain some ceilometer knowledge into nova, like metering interval etc.

Thanks
--jyh

> 
> --
> Russell Bryant
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev