On Wed, May 2, 2012 at 10:28 AM, Loic Dachary <[email protected]> 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] -Rob _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
