On Thu, 4 Sep 2014, Flavio Percoco wrote: Thanks for writing this up, interesting read.
5. Ceilometer's recommended storage driver is still MongoDB, although Ceilometer has now support for sqlalchemy. (Please correct me if I'm wrong).
For sake of reference: Yes, MongoDB is currently the recommended store and yes, sqlalchemy support is present. Until recently only sqlalchemy support was tested in the gate. Two big changes being developed in Juno related to storage: * Improved read and write performance in the sqlalchemy setup. * time series storage and Gnocchi: https://julien.danjou.info/blog/2014/openstack-ceilometer-the-gnocchi-experiment
I truly believe, with my OpenStack (not Zaqar's) hat on, that we can't keep avoiding these technologies. NoSQL technologies have been around for years and we should be prepared - including OpenStack operators - to support these technologies. Not every tool is good for all tasks - one of the reasons we removed the sqlalchemy driver in the first place - therefore it's impossible to keep an homogeneous environment for all services.
+1. Ain't that the truth.
As mentioned in the meeting on Tuesday, Zaqar is not reinventing message brokers. Zaqar provides a service akin to SQS from AWS with an OpenStack flavor on top. [0]
In my efforts to track this stuff I remain confused on the points in these two questions: https://wiki.openstack.org/wiki/Zaqar/Frequently_asked_questions#How_does_Zaqar_compare_to_oslo.messaging.3F https://wiki.openstack.org/wiki/Zaqar/Frequently_asked_questions#Is_Zaqar_an_under-cloud_or_an_over-cloud_service.3F What or where is the boundary between Zaqar and existing messaging infrastructure? Not just in terms of technology but also use cases? The answers above suggest its not super solid on the use case side, notably: "In addition, several projects have expressed interest in integrating with Zaqar in order to surface events..." Instead of Zaqar doing what it does and instead of oslo.messaging abstracting RPC, why isn't the end goal a multi-tenant, multi-protocol event pool? Wouldn't that have the most flexibility in terms of ecosystem and scalability?
In addition to the aforementioned concerns and comments, I also would like to share an etherpad that contains some use cases that other integrated projects have for Zaqar[0]. The list is not exhaustive and it'll contain more information before the next meeting. [0] https://etherpad.openstack.org/p/zaqar-integrated-projects-use-cases
For these, what is Zaqar providing that oslo.messaging (and its still extant antecedents) does not? I'm not asking to naysay Zaqar, but to understand more clearly what's going on. My interest here comes from a general interest in now events and notifications are handled throughout OpenStack. Thanks. -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
