Open Stack

On Jan 30, 2013, at 8:39 AM, Julien Danjou wrote:

> On Wed, Jan 30 2013, Sandy Walsh wrote:
> 
>> I don't understand the difference? Metering assumes archiving. If any
>> company with SEC requirements wants to use Ceilometer for billing, for
>> example, they'll have to store 90+ days of data.
>> 
>> Can you elaborate on the ceilometer mandate?
> 
> Notifications aren't all about metering. Actually, they are called
> "notifications", not "meters". Things would be different if
> Nova/Glance/etc would emit directly meters, for example (hint hint).

One of the primary use cases the notification system in Nova was created for was usage metering for billing. 
They are designed to be 'clicks' on a counter, i.e. get a compute.instance.create -> click 'number of instances for tenant $tenant_id' up one, 
if it's a Windows instance, click '# of windows licenses' up one, etc. 

The way I understand Ceilometer's meters, is that they are the counters in this situation. (or at least these counters would be one type of meter) 
(correct me if I'm confused on any of this. I'm still getting used to ceil's terminology.)

The reason nova, etc doesn't actually do the counters is for scalability reasons (don't want to drag down the system with historical data on x * 1e5 instances per cell)
and because exactly *what* counters we want to tick on each event involves all sorts of business logic, thus needing some complex configuration/config api, thus is something more suited to an application designed for the purpose. 


> Remember that Ceilometer is also providing an API endpoint to be
> queried, and what it stores via its `collector' is directly made to be
> used via its API.
> So the essence of the collector service is to treat and transform
> notifications into meters. To do metering.
> 
> Now, if what you want is to archive all notifications and build meters
> From that, there's a couple of solution, based on and around Ceilometer,
> but I don't think Ceilometer is going to be enough.
> 
> For example, you could have a smaller project just listening to
> notifications and storing them in a databse like StackTach does, and
> move the metering part into Ceilometer.
> Or you could write a driver notifier storing directly the notification
> into a database actually, I guess that depends on what you want to
> achieve.
> 
> But Ceilometer itself has no use of the raw notificatins once it has
> transformed them into meters.
> 
>> Sorry, I still trip over the ceilometer terminology. I was citing your
>> comment above about "Ceilometer notification plugin" ... and the only
>> one I was aware of was the one here:
>> https://github.com/openstack/ceilometer/blob/master/ceilometer/compute/nova_notifier.py
>> 
>> And, if so, I was saying that's the thing we don't really need.
> 
> Ah right, I get it. No, I was talking about plugin.NotificationBase,
> which is the way you can handle notifications coming from Nova (or other
> OpenStack components) in Ceilometer.
> You can write a plugin using that (that will be used by
> ceilometer-collector) to listen to (all) notifications and build any
> meter. And even more complicated meter with transformers.
> 
> -- 
> Julien Danjou
> -- Free Software hacker & freelance
> -- http://julien.danjou.info
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev