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'vebeen 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 helpdriving 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
signature.asc
Description: PGP signature
__________________________________________________________________________ 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
