[openstack-dev] [all] [qpid] [zmq] [RabbitMQ] [oslo] Pending deprecation of driver(s).
davanum at gmail.com
Tue Jun 23 15:47:15 UTC 2015
We can generate options, if folks who need/want it are not here to do
the necessary work, not much we can do :(
On Tue, Jun 23, 2015 at 11:30 AM, Joshua Harlow <harlowja at outlook.com> 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/
>>>> > Cheers,
>>>> 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
>>>> as is.
>>> 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
>>> stay in
>>> 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):
> - https://github.com/celery/kombu/blob/master/kombu/transport/qpid.py#L1250
> - https://github.com/celery/kombu/blob/master/kombu/transport/qpid.py#L1210
> 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 support/make
> 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
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
Davanum Srinivas :: https://twitter.com/dims
More information about the OpenStack-dev