Open Stack

On Thu, May 3, 2012 at 11:59 AM, Loic Dachary <loic at enovance.com> wrote:

> 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.
>

Do you envision that writing to AMQP directly, or using the existing
notification API (which seems to be a wrapper over the RPC layer, which is
in turn a wrapper for AMQP)?


> >  - 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
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120504/bff4a097/attachment.html>