Open Stack

Flavio Percoco wrote:
> 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/
>>>>>>
>>>>>> 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
>>>>> convoluted...historical...
>>>>>
>>>>> 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 possible.
>
> 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.
>
> Cheers,
> Flavio

Understood, I see the benefit of going both ways and I am fine with 
however it turns out...

>
>
>>
>> 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.
>>>
>>> Cheers,
>>> Flavio
>>>
>>>>
>>>> __________________________________________________________________________
>>>>
>>>>
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>> __________________________________________________________________________
>>>
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>