On 05/03/2012 09:58 AM, Robert Collins wrote: > On Wed, May 2, 2012 at 10:28 AM, Loic Dachary <l...@enovance.com> wrote: > >> As I wrote in a previous mail, once we manage to provide an implementation >> that proves useful, we will be in a position to approach the core OpenStack >> components. Integrating the metering agents as part of the core component, >> much in the same way it's currently done in nova. That will reduce the >> overall complexity of deploying OpenStack with metering (which must not be >> mandatory). However, there is very little chance that all components >> developed around OpenStack are convinced and there will always be a need for >> a metering that is external to the component. Therefore, even if metering >> eventually manages to become a first class concern for the core OpenStack >> components, the proposed architecture of the metering project ( per node >> agents when necessary and a collector harvesting them into a storage ) will >> keep being used for other components. >> >> Do you think I'm wrong ? We're at a very early stage and now is the time to >> question everything :-) > I would avoid node agents as a primary interface: they can always be > written to workaround components that don't provide metering > themselves - like the nagios plugins example given by Andrew. node > agents are more complex than implementing metering in each component > because they require a handoff, parsing of local logs (or whatever > relevant store the component uses), and they are another process to > keep running; they probably devolve to polling, and polling is a good > way to use a lot of resources up :(. > > The key thing I see is having a clear contract for how metering is > done, so that anyone writing a new component can add metering easily. > This is easier for the component author than having to write their > component *and* write a metering node agent for that component. > > E.g. > - define the signals, extension points, and python API for > implementing metering in a component. > - implement a no-op implementation of that metering API which > discards all data. > - implement a AMQP based implementation which shoves all the data out > to some queue somewhere. > - submit patches to existing components to add metering > - and if a component owner rejects metering altogether, you can still > implement a node agent to gather the data and push it out via the > metering API - that will always be an option. > > Then we will have a situation where: > - new components can meter easily > - folk with different delivery constraints can change the network > layer easily (drop in a different implementation of the Python API) > [e.g. to log directly to a NoSQL store] I could not agree more. This way we have the best of both worlds : integration in components when possible and standalone agents when it can't be done for whatever reason.
Cheers -- Loïc Dachary Chief Research Officer // eNovance labs http://labs.enovance.com // ✉ l...@enovance.com ☎ +33 1 49 70 99 82 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
