On 14/04/15 19:54 -0400, Sean Dague wrote:
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.

The only reason I proposed to move it in a separate repo is to provide
sort of a deprecation path that won't block our work towards Py3K. In
the stripped part of my previous email I also mentioned that we could
mark it as deprecated to make clear what our intentions going forward
are.

I don't agree that "just killing it" is the right thing to do here.
Doing this will give us a bit more work to do since we'll have to go
through the repo creation process but at least we don't risk to be
blamed for killing people's deployments out of the blue.

Cheers,
Flavio

--
@flaper87
Flavio Percoco

Attachment: pgpTJCV0xh7L4.pgp
Description: PGP signature

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to