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 [fla...@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 <fla...@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 > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev