Open Stack

Excerpts from joehuang's message of 2016-09-06 02:12:45 +0000:
> 
> > 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

oslo.messaging is the abstraction layer you're looking for. Put the new
features there.

Doug

> 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
>