Open Stack

Hello,

My idea for Ceilometer scaling is to partition Ceilometer based on project ID  ( Sorry I am newbie to Ceilometer, correct me if I am wrong ).

Why?

1. Each tenant only cares about the metering data/event/alarm for himself, doesn't cares who else is also using the ceilometers. Project ID could be the orthogonal partition factor for all data stored/evaluated in Ceilometer. That means we don't need to store all projects' data into a same huge storage system, multiple storage backend for different project set can be used in Ceilometer. One front routing layer (based on project ID) can be added before data stored into or retrieved from Ceilometer storage. 

2. Polling/collect data on demand. Only if the data has been asked by the tenant, then metering and sampling data will be collected. A tenant is not allowed to use all meter by default, meters/samples could be configured and billing-able. One project ID often has limited corresponding resources, and tenant need to pay for advanced functionality provided by Ceilometer ( how often, how much ). After partition, more physical resource could be allocated to serve some project, but the project must pay more for extra physical resources used. 

Best Regards
Chaoyi Huang ( Joe Huang )

-----Original Message-----
From: gordon chung [mailto:gord at live.ca] 
Sent: Wednesday, May 27, 2015 9:03 AM
To: OpenStack Development Mailing List not for usage questions
Subject: Re: [openstack-dev] [ceilometer][all] Scalable metering

hi Tim,

we're still doing some investigation but we're tracking/discussing part of the polling load issue here: https://review.openstack.org/#/c/185084/

we're open to any ideas -- especially from nova api et al experts.

cheers,
gord


________________________________
> From: Tim.Bell at cern.ch
> To: openstack-dev at lists.openstack.org
> Date: Tue, 26 May 2015 17:45:37 +0000
> Subject: [openstack-dev] [ceilometer][all] Scalable metering
> 
> 
> 
> 
> We had a good discussion at the summit regarding ceilometer scaling. 
> Julien has written up some of the items discussed in 
> https://julien.danjou.info/blog/2015/openstack-summit-liberty-vancouve
> r-ceilometer-gnocchi and there is work ongoing in the storage area for 
> scalable storage of ceilometer data using gnocchi.
> 
> 
> 
> I'd like community input on the other scalability concern raised 
> during the event, namely the load on other services when ceilometer is 
> enabled. From the blog, "Ceilometer hits various endpoints in 
> OpenStack that are poorly designed, and hitting those endpoints of 
> Nova or other components triggers a lot of load on the platform.".
> 
> 
> 
> I would welcome suggestions on how to identify the potential changes 
> in the OpenStack projects and improve the operator experience when 
> deploying metering.
> 
> 
> 
> Tim
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ______________________________________________________________________
> ____ OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 		 	   		  
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev