openstack team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

On Wed, May 2, 2012 at 10:28 AM, Loic Dachary <loic@xxxxxxxxxxxx> 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