<br><br><div class="gmail_quote">On Thu, Nov 15, 2012 at 6:44 AM, Jiang, Yunhong <span dir="ltr"><<a href="mailto:yunhong.jiang@intel.com" target="_blank">yunhong.jiang@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">> ><br>
> > But is Nova ready to import (optionnaly) some ceilometer code?<br>
><br>
> So there appears to be some support from the ceilo side emerging<br>
> for option #4, and you've hit the nail on the head there with that<br>
> final question ...<br>
><br>
> Would the nova project be happy to accept:<br>
><br>
>  (a) the ceilo compute agent repackaged as nova-compute-metering<br>
><br>
<br>
</div>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.<br>

<br>
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.<br></blockquote><div><br></div><div>This is where I was starting, too, although I'm not sure it supports all of our use cases for monitoring.</div>
<div><br></div><div>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.</div>
<div><br>Doug</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> and,<br>
><br>
>  (b) the deployment of an additional daemon per compute node<br>
><br>
> It would be great if we could get some response to the above from<br>
> the nova "leadership" (loosely defined).<br>
><br>
> Just to muddy the waters further if I may, let me throw a further<br>
> option into the mix:<br>
><br>
> 5. nova packages a consumable library layered over the hypervisor<br>
>    driver, that just exposes the diagnostics available from libvirt<br>
>    et al. The ceilo compute agent continues to exist under the ceilo<br>
>    umbrella, but talks to the hypervisor directly via this stable,<br>
>    versioned nova library.<br>
><br>
>    + no remote calls required from ceilo-->nova-{api|compute}<br>
>    - needs an independent versioning scheme<br>
>    - still stuck in the "implicit trust" model?<br>
<br>
</div>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?<br>
<br>
<br>
--jyh<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Thoughts?<br>
><br>
> Cheers,<br>
> Eoghan<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br>