[openstack-dev] [all] QPID incompatible with python 3 and untested in gate -- what to do?

Flavio Percoco flavio at redhat.com
Thu Apr 16 07:20:27 UTC 2015

On 15/04/15 09:09 -0700, Joshua Harlow wrote:
>Flavio Percoco wrote:
>>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):
>>>>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
>>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.
>If it isn't working in the gate and/or maintained, exactly whose 
>deployments are working (for some definition of working) to 'kill' in 
>the first place? Seems like it has to work at least in the gate for 
>people to have deployments that work in the first place, otherwise 
>they likely don't have deployments that could be 'killed' in the first 
>place, right?

The problem bein raised in this thread is that it doesn't work with
py3k and we want to move forward to have a fully py3k compatible
oslo.messaging. Therefore, we need to either fix the non-py3k
compatible drivers or pull them out of the code base.

I don't think anyone said it's not working in the gate and we're not
100% sure it's not being used. The proposal is to not kill it now but
later. Therefore, pull it out of the repo, let people know it's going
to be killed and then kill it.


>/me not saying that we should 'kill' it as the best way, just if it 
>doesn't work then it doesn't seem to do much harm to 'kill' it...
>>OpenStack Development Mailing List (not for usage questions)
>>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe

Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150416/e498566d/attachment-0001.pgp>

More information about the OpenStack-dev mailing list