Open Stack

Daniel raised a good point, I also agreed that is not a good architecture.
Nova can't touch any monitoring stuffs - I don't think that is good.
At least, Ceilometer can be a monitoring hub for external utilities.

On the other hand, for the options Lianhao raised.
Is a query on a DB and a json column faster than the one on two-DB join?
I have no experimental data but I doubt it.

Thanks.
--
Shane

Dan Smith wrote on 2013-07-20:

>> IIUC, Ceilometer is currently a downstream consumer of data from
>> Nova, but no functionality in Nova is a consumer of data from
>> Ceilometer. This is good split from a security separation point of
>> view, since the security of Nova is self-contained in this
>> architecture.
>> 
>> If Nova schedular becomes dependant on data from ceilometer, then now
>> the security of Nova depends on the security of Ceilometer, expanding
>> the attack surface. This is not good architecture IMHO.
> 
> Agreed.
> 
>> At the same time, I hear your concerns about the potential for
>> duplication of stats collection functionality between Nova &
>> Ceilometer. I don't think we neccessarily need to remove 100% of
>> duplication. IMHO probably the key thing is for the virt drivers to
>> expose a standard API for exporting the stats, and make sure that
>> both ceilometer & nova schedular use the same APIs and ideally the
>> same data feed, so we're not invoking the same APIs twice to get the
>> same data.
> 
> I imagine there's quite a bit that could be shared, without dependency
> between the two. Interfaces out of the virt drivers may be one, and the
> code that boils numbers into useful values, as well as perhaps the
> format of the JSON blobs that are getting shoved into the database.
> Perhaps a ceilo-core library with some very simple primitives and
> definitions could be carved out, which both nova and ceilometer could
> import for consistency, without a runtime dependency?
> 
> --Dan
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev