Open Stack

On 5 September 2016 at 17:08, Flavio Percoco <flavio at redhat.com> wrote:

> We should probably start by asking ourselves who's really being bitten by
> the
> messaging bus right now? Large (and please, let's not bikeshed on what a
> Large
> Cloud is) Clouds? Small Clouds? New Clouds? Everyone?
> The we can start asking ourselves things like: Would a change of the
> API/underlying technology help them? Why? How? What technology exactly and
> why?
> What technology would make their lives simpler and why?
>

Well, as far as RabbitMQ goes, then I would certainly say in deployment
it's not a pleasant thing to work with.  Even if you consider it good
enough day to day (which is debatable) then consider its upgradeability -
it's impractical to keep it running as you upgrade it, is my
understanding.  It would also seem to be a big factor in our scale
limitations - I wonder if we could do without such complexities as cells if
we had something a bit more performant (with perhaps a more lax operating
model).

But this is not about blaming Rabbit for all our problems.  The original
statement was that RPC is a bad pattern to use in occasionally unreliable
distributed systems, and Rabbit in no ways forces us to use RPC patterns.
That we don't see the RPC pattern's problems so clearly is because a fault
happening at just the right time in a call sequence to show up the problem
rarely happens, and testing such a fault using injection is not practical -
but it does happen in reality and things do go weird when it happens.

The proposal was to create a better interface in oslo for a comms model
(that we could implement - and regardless of how we chose to implement it -
and that would encourage people to code for the corner cases) and then
encourage people to move across.

I'm not saying this research/work is not useful/important (in fact, I've
> been
> advocating for it for almost 2 years now) but I do want us to be more
> careful
> and certainly I don't think this change should be anything but transparent
> for
> every deployment out there.
>

That is a perfectly reasonable thing to ask.  I presume by transparent you
mean that the standard upgrade approaches will work.

To answer this topic more directly. As much as being opinionated would help
> driving focus and providing a better result here, I believe we are not
> there yet
> and I also believe a backend agnostic API would be more benefitial to begin
> with. We're not going to move 98% of the OpenStack deployments out there
> off of
> rabbitmq just like that.
>

Again, this originally wasn't about Rabbit, or having a choice of
backends.  One backend would do if that backend were perfect for the job.
There are other reasons for doing this that would hopefully make OpenStack
more robust.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160905/ee78482b/attachment.html>