Open Stack

On 05/03/2012 09:58 AM, Robert Collins wrote:
> On Wed, May 2, 2012 at 10:28 AM, Loic Dachary <loic at 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
// ✉ loic at enovance.com  ☎ +33 1 49 70 99 82