Open Stack

Excerpts from Sean Dague's message of 2015-04-14 16:54:30 -0700:
> On 04/14/2015 07:26 PM, Flavio Percoco wrote:
> > On 14/04/15 23:18 +0000, Jeremy Stanley wrote:
> >> On 2015-04-15 01:10:03 +0200 (+0200), Flavio Percoco wrote:
> >> [...]
> >>> I'd recommend sending this email to the ops mailing list
> >>
> >> And I'd recommend subscribing to it... it's really quite good! He
> >> did (twice apparently, I expect the second by mistake):
> >>
> >> http://lists.openstack.org/pipermail/openstack-operators/2015-April/006735.html
> >>
> > 
> > It'd have been useful to have this linked in this thread...
> > 
> >>
> >>> and the users mailing list too.
> >> [...]
> >>
> >> The general mailing list seems a little less focused on this sort of
> >> thing, but I suppose it can't hurt.
> > 
> > I disagree, they are still users and we get feedback from them.
> 
> There is a problem with sending out an "is anyone using this?" email and
> deciding whether or not to do this based on that. You're always going to
> find a few voices that pop up.
> 
> We've gotten a ton of feedback from operators, both via survey, and
> meetups. And the answer is that they are all running Rabbit. Many have
> tried to run one of the other backends because of Rabbit bugs, and have
> largely found them worse, and moved back.
> 
> The operator community has gathered around this backend. Even though
> it's got it's issues, there are best practices that people have come to
> develop in dealing with them. Making this pluggable doesn't provide a
> service to our users, because it doesn't make it clear that there is 1
> backend you'll get help from others with, and the rest, well you are
> pretty much on your own, good luck, and you get to keep all the parts.
> Writing a "seemingly correct" driver for oslo.messaging doesn't mean
> that it's seen the kind of field abuse that's really needed to work out
> where the hard bugs are.
> 
> It's time to be honest about the level of support that comes with those
> other backends, deprecate the plugability, and move on to more
> interesting problems. We do have plenty of them to solve. :) Perhaps in
> doing so we could get a better Rabbit implementation and make life
> easier for everyone.
> 

I think you're right about most of this, so +1*

*I want to suggest that having this pluggable isn't the problem. Merging
drivers without integration testing and knowledgeable resources from
interested parties is the problem. If there isn't a well defined gate
test, and a team of people willing to respond to any and all issues with
that infrastructure committed, then the driver should not be shipped
with oslo.messaging.

We've been through this already with the virt drivers and
databases. Having the ability to move into a space that a different
backend serves well is a good feature. We *will* hit the limits of
Rabbit. Encouraging users to submit every possible backend has costs
though. This neighborhood has been gentrified, and it's time to evict
anyone not willing or able to pay the rent.

This thread has convinced me that the right path is to make an
announcement, and deprecate the QPID driver as of the next release of
oslo.messaging. We can always reverse that decision if users actually
show up. Then the usual 2 cycle dance and we're relieved of, oddly
enough, 666 SLOC:

$ radon raw oslo_messaging/_drivers/impl_qpid.py
oslo_messaging/_drivers/impl_qpid.py
    LOC: 794
    LLOC: 430
    SLOC: 666
    Comments: 50
    Multi: 72
    Blank: 128
    - Comment Stats
        (C % L): 6%
        (C % S): 8%
        (C + M % L): 15%