Open Stack

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