[openstack-dev] [all] [qpid] [zmq] [RabbitMQ] [oslo] Pending deprecation of driver(s).
flavio at redhat.com
Tue Jun 23 16:21:22 UTC 2015
On 23/06/15 08:30 -0700, Joshua Harlow wrote:
>Flavio Percoco wrote:
>>On 22/06/15 12:43 -0700, Clint Byrum wrote:
>>>Excerpts from Adam Young's message of 2015-06-22 11:26:54 -0700:
>>>>On 06/20/2015 10:28 AM, Flavio Percoco wrote:
>>>>> As promissed: https://review.openstack.org/#/c/193804/
>>>>You can't deprecate a driver without providing a viable alternative.
>>>>Right now, QPID is the only driver that supports Kerberos.
>>>>TO support Kerberos, tyou need support for the GSSAPI library, which is
>>>>usually done via support for SASL. Why is it so
>>>>We've talked with both teams (I work with Ken) and I think Proton is
>>>>likely going to be the first to have support. The folks working on
>>>>Rabbit have the double hurdle of getting SASL support into Erlang first,
>>>>and then support for SASL into Rabbit. They've indicated a preference
>>>>for getting it in to the AMQP 1.0 driver, and not bothering with the
>>>>exisiting, but, check me on this, the Oso.Messaging code only support
>>>>the pre 1.0 Rabbit.
>>>>So..until we have a viable alternative, please leave QPID alone. I've
>>>>not been bothering people about it, as there seems to be work to get
>>>>ahead, but until either Rabbit or Proton support Kerberos, I need QPID
>>>Adam that is all great information, thank you. However, the policy is
>>>clear: commit resources for integration testing, or it needs to move
>>>out of tree.
>>>It's not a mountain of resources. Just an integration test that passes
>>>reliably, and a couple of QPID+OpenStack experts who we can contact when
>>>it breaks. If nobody is willing to put that much effort in, then it is
>>>not really something we want in our official messaging library tree.
>>>So please if you can carry that message up to those who want it to
>>>tree, that would be helpful and would put the stops on this deprecation.
>>Agreed with the above.
>>I'd also like to add that it was also discussed with folks previously
>>maintaining the qpid driver what their plans with that work were and
>>the agreement of deprecating it was reached with them.
>Just to note, something that may be acceptable for people that need
>this, and don't mind doing a little bit of work to maintain it out of
>tree. It appears the kombu qpid driver does have SASL support (from a
>quick glance at the code):
>So until this gets resolved and/or maintained it appears folks could
>just use the one built-in to kombu (assuming it works)? If the
>oslo.messaging 'impl_rabbit.py' one was more of a kombu 'wrapper' (and
>renamed 'impl_kombu.py'?) than this might have been even easier to
TBH, I'm more for making the impl_rabbit driver more "rabbit-focused"
rather than more "kombu-focused". Using kombu for it is great and I
wouldn't advice to move away from it (not in the short run at least).
But if there are changes that we can do to make it more rabbit
specific, I'd be all for that.
>Food for thought :)
>>I know this doesn't solve the current problem of not having kerberos
>>support but it clears that this discussion has been had already.
>>That said, the point being raised is very good and unfortunate.
>>>OpenStack Development Mailing List (not for usage questions)
>>>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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: not available
More information about the OpenStack-dev