openstack team mailing list archive

[Mark McLoughlin <markmc@xxxxxxxxxx>]

Hi Loic,

On Mon, 2012-04-30 at 12:15 +0200, Loic Dachary wrote:

> To prepare for the next meeting ( thursday 3rd, may 2012
> http://wiki.openstack.org/Meetings/MeteringAgenda ) I cleaned up and
> reorganized the Metering blueprint so that it ( hopefully )
> incorporates all the information temporarily stored in the etherpad
> ( http://etherpad.openstack.org/EfficientMetering revision 67 in case
> it is vandalized ).

I'm a bit late to the discussion, but some brief comments after reading
up on what you guys have done so far:

  - big +1 on separating billing from metering; there's no need to 
    conflate the two problems and doing it this way will allow for a 
    bunch of different ideas to be tried around billing

  - I'd prefer to avoid adding a new node agents, so +1 on building on
    the notifications system

  - I agree that we don't want to go too far with aggregation and lose 
    useful data like which instances have been running as opposed to 
    just how many instance minutes a given tenant has consumed

    Another aspect of aggregation to think about is aggregation over 
    time - e.g. I might like to see my hourly network usage has varied 
    over the last week, or how my daily usage has varied over the last 
    month, but I probably don't care so much about my hourly usage on a 
    specific day 3 months ago

    oVirt's equivalent of a metering service does this kind of 
    aggregation as follows:

      http://www.ovirt.org/wiki/Ovirt_DWH

        * Sample data is collected at the end of every minute and is
          kept for up to 48 hours.
        * Hourly level is aggregated every hour for the hour before 
          last and is kept for 2 months.
        * Daily level is aggregated every day for the day before last
          and is kept for 5 years. 

  - Lastly, bikeshed mode - since we're calling this "metering" and not 
    "counting", how about just using the term "meters" rather than 
    "counters"?

Cheers,
Mark.