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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
