- Original Message -
> From: "Murali Allada" <murali.all...@rackspace.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Sent: Thursday, 10 September, 2015 6:41:40 AM
> Subject: [openstack-dev] [magnum] keystone pluggable model
>
>
>
> Hi All,
>
>
>
>
>
> In the IRC meeting yesterday, I brought up this new blueprint I opened.
>
>
>
>
>
> https://blueprints.launchpad.net/magnum/+spec/pluggable-keystone-model
>
>
>
>
>
> The goal of this blueprint is to allow magnum operators to integrate with
> their version of keystone easily with downstream patches.
>
>
>
>
>
> The goal is NOT to implement support for keystone version 2 upstream, but to
> make it easy for operators to integrate with V2 if they need to.
>
>
>
>
>
> Most of the work required for this is already done in this patch.
>
>
>
>
>
> https://review.openstack.org/#/c/218699
>
>
>
>
>
> However, we didn't want to address this change in the same review.
>
>
>
>
>
> We just need to refactor the code a little further and isolate all version
> specific keystone code to one file.
>
>
>
>
>
> See my comments in the following review for details on what this change
> entails.
>
>
>
>
>
> https://review.openstack.org/#/c/218699/5/magnum/common/clients.py
>
>
>
>
>
> https://review.openstack.org/#/c/218699/5/magnum/common/keystone.py
>
>
>
>
>
> Thanks,
>
>
> Murali
Hi,
My keystone filter picked this up from the title so i don't really know
anything specifically about magnum here, but can you explain what you are
looking for in terms of abstraction a little more?
Looking at the review the only thing that magnum is doing with the keystone API
(not auth) is trust creation - and this is a v3 only feature so there's not
much value to a v2 client there. I know this is a problem that heat has run
into and done a similar solution where there is a contrib v2 module that short
circuits some functions and leaves things somewhat broken. I don't think they
would recommend it.
The other thing is auth. A version independent auth mechanism is something that
keystoneclient has supplied for a while now. Here's two blog posts that show
how to use sessions and auth plugins[1][2] from keystoneclient such that it is
a completely deployment configuration choice what type (service passwords must
die) or version of authentication is used. All clients i know with the
exception of swift support sessions and plugins so this would seem like an
ideal time for magnum to adopt them rather than reinvent auth version
abstraction as you'll get some wins like not having to hack in already
authenticated tokens into each client.
From the general design around client management it looks like you've taken
some inspiration from heat so you might be interested in the recently merged
patches there that convert to using auth plugins there.
If you need any help with this please ping me on IRC.
Jamie
[1]
http://www.jamielennox.net/blog/2014/09/15/how-to-use-keystoneclient-sessions/
[2] http://www.jamielennox.net/blog/2015/02/17/loading-authentication-plugins/
> __
> 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
