From my understanding it would be a cleanup operation - which to be
honest, would be very much welcomed. I recently did a little work with
Castellan to integrate it with Murano and found the auth code to be very
messy, and flat out broken in some cases. If it's possible to let the
barbican client take care of this that sounds good to me.
> Which mode is used the most in the services that consume castellan
> today?
Afaik Barbican is the only backend that currently exists in Castellan
[0]. Looking again it seems some support has been added for vault which
is great, but I reckon Barbican would still be the primary use.
I haven't been hugely active in Castellan but if the team would like
some more input on this or reviews please do ping me, I'd be glad to help.
-Paul
[0] https://github.com/openstack/castellan/tree/master/castellan/key_manager
On 06/12/17 22:12, Doug Hellmann wrote:
Excerpts from Gage Hugo's message of 2017-12-06 15:16:14 -0600:
It's been a bit since the summit but I believe this was also discussed at
the Denver PTG as well: https://etherpad.openstack.org/p/oslo-ptg-queens
The keystoneauth stuff seems to be more from Sydney, but if I remember
correctly, Castellan authenticates through keystoneauth and passes the
session to barbicanclient. This is the only use of keystoneauth within
Castellan, so one idea that was mentioned was to see if Castellan could
simply pass the credentials to barbicanclient, which would auth through
keystoneauth instead, removing the dependency from Castellan.
It looks like Castellan tries to authenticate using the token from
the context in two separate cases [1]. That would cause the service
using castellan to connect to barbican as the user making the API
request. Removing the use of keystoneauth would mean that feature
would no longer work, and all requests to barbican would be made
as a hard-coded user. That seems like a pretty fundamental difference
in behavior.
Which mode is used the most in the services that consume castellan
today?
I'm still not understanding the real motivation for removing the
dependency. Is it just someone's notion of cleaning things up? Or is
there a runtime issue of some sort?
Doug
[1]
http://git.openstack.org/cgit/openstack/castellan/tree/castellan/key_manager/barbican_key_manager.py#n140
On Tue, Dec 5, 2017 at 10:54 AM, Doug Hellmann <d...@doughellmann.com>
wrote:
Excerpts from ARORA, ROHAN's message of 2017-12-05 14:37:49 +0000:
So from my understanding now, we are wanting to remove the HARD
dependency on Keystoneauth, not to remove it completely since that would
break the barbican client. Currently seeing if we just remove the
dependency from requirements.txt, if that stops Keystoneauth from being
used until you try to use the barbican.
There would need to be more changes than that, because we still need the
package to be installed for testing the Barbican driver.
Maybe if someone could explain what the issue is, I can offer more
detailed advice. What is wrong with having the keystoneauth dependency?
Is it breaking something? Is it interfering with some other library?
Doug
__________________________________________________________________________
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
