Open Stack

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.

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