Open Stack

On Thu, Nov 15, 2012 at 6:44 AM, Jiang, Yunhong <yunhong.jiang at intel.com>wrote:

> > >
> > > But is Nova ready to import (optionnaly) some ceilometer code?
> >
> > So there appears to be some support from the ceilo side emerging
> > for option #4, and you've hit the nail on the head there with that
> > final question ...
> >
> > Would the nova project be happy to accept:
> >
> >  (a) the ceilo compute agent repackaged as nova-compute-metering
> >
>
> I think put the whole ceilometer-compute-agent, including data collection,
> i.e. pollster, multiple publisher, data translation, publisher, into nova
> is a bit overload IMHO. I'd suggest nova to only collect raw data as
> mentioned in another mail, and have Ceilometer handle the multiple
> publisher, translation etc.
>
> The lag of RPC does not matter, the lag of data collection caused by nova
> overload matters. I think that's the reason of the daemon proposed.
>

This is where I was starting, too, although I'm not sure it supports all of
our use cases for monitoring.

We've shown that we can meter without tight integration, but I don't think
we're going to get effective monitoring without tighter integration between
the projects. Nova has access to the data while ceilometer knows how often
it needs to be collected and where it needs to go.

Doug


>
> > and,
> >
> >  (b) the deployment of an additional daemon per compute node
> >
> > It would be great if we could get some response to the above from
> > the nova "leadership" (loosely defined).
> >
> > Just to muddy the waters further if I may, let me throw a further
> > option into the mix:
> >
> > 5. nova packages a consumable library layered over the hypervisor
> >    driver, that just exposes the diagnostics available from libvirt
> >    et al. The ceilo compute agent continues to exist under the ceilo
> >    umbrella, but talks to the hypervisor directly via this stable,
> >    versioned nova library.
> >
> >    + no remote calls required from ceilo-->nova-{api|compute}
> >    - needs an independent versioning scheme
> >    - still stuck in the "implicit trust" model?
>
> I think this is similar to my above statement, the only difference is the
> direction, and I think you still need remove call, otherwise, what will be
> the communication channel?
>
>
> --jyh
>
> >
> > Thoughts?
> >
> > Cheers,
> > Eoghan
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121115/e0ab83b6/attachment.html>