Open Stack

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

> 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