openstack team mailing list archive

[Loic Dachary <loic@xxxxxxxxxxxx>]

On 05/02/2012 07:39 AM, Mark McLoughlin wrote:
> On Tue, 2012-05-01 at 23:05 +0200, Loic Dachary wrote:
>> On 05/01/2012 06:13 PM, Mark McLoughlin wrote:
>>> 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 would also prefer this option. I have a few concerns though:
>>
>> a) adding too many messages to the existing message queues
>> b) not all core components provide notifications
>> c) convincing all components to agree on a unified approach to metering
>>
>> Instead it might be more practical to implement node agents when
>> necessary to complete a first implementation. That is, taking advice
>> from core component developers and possibly run into problems as
>> opposed to convincing core component developers to adopt an approach
>> to metering that is not yet implemented anywhere.
> I'd start with metering using the notifications which are already there.
> I think that will get us a long way.
I've started a thread to check there is all we need and if not to figure out how it can be modified.
>
> My impression is that the notifications system is intended to cover all
> billable usage in at least Nova and Glance.
It's also my understanding. Regarding swift, how would you suggest we approach the problem ? I see two possible courses:

a) directly create something similar to nova http://wiki.openstack.org/SystemUsageData for swift (i.e. a swift blueprint and coding in swift ) so that there is no need to install a metering agent for swift
b) create a swift plugin for a metering agent and when it proves useful, port it to swift so that it is integrated and there is no longer a need for a metering agent plugin

What do you think ?

-- 
Loïc Dachary         Chief Research Officer
// eNovance labs   http://labs.enovance.com
// ✉ loic@xxxxxxxxxxxx  ☎ +33 1 49 70 99 82