On Thu, May 3, 2012 at 11:59 AM, Loic Dachary <l...@enovance.com> wrote:
> 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. > 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 > // ✉ 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 >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp