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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
