[openstack-dev] [all][massively distributed][architecture]Coordination between actions/WGs

joehuang joehuang at huawei.com
Tue Sep 6 02:12:45 UTC 2016


> A full rewrite of the library that doesn't take under consideration the existing
> deployed technologies is not going to be of any help, IMHO. The reason being
> that upgradability would be broken and that's a no-go. I believe Clynt was
> trying to make the same point when he brought up the choice of backends up.

+1.

That's why I proposed to provide plugin mechanism in Nova/Cinder API layer, this layer
abstract can hide the difference of messaging library, and ensure the
existing implementation always work and successfully fallback during upgrade if necessary
and this way makes the upgrade easier to manage, and a cleaner and more steady
interface to do improvement step by step.

Best Regards
Chaoyi Huang (joehuang)

________________________________________
From: Flavio Percoco [flavio at redhat.com]
Sent: 05 September 2016 20:52
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all][massively distributed][architecture]Coordination between actions/WGs

On 05/09/16 18:55 +0700, Ian Wells wrote:
>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.

I did not mean to say Rabbit is to blame, if anything I meant to say that things
have gotten better from the Rabbit side. My point is that OPs/Deployments must
be taken under consideration on this refactor.

A full rewrite of the library that doesn't take under consideration the existing
deployed technologies is not going to be of any help, IMHO. The reason being
that upgradability would be broken and that's a no-go. I believe Clynt was
trying to make the same point when he brought up the choice of backends up.

As I mentioned in my previous email, I'm all for having a better messaging API
that is backend agnostic, even if we end up using a single backend in the Z^2
release.

Hope it's clearer now,
Flavio

--
@flaper87
Flavio Percoco



More information about the OpenStack-dev mailing list