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 // ✉ [email protected] ☎ +33 1 49 70 99 82 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
