Open Stack

----- Original Message -----
> From: "Murali Allada" <murali.allada at RACKSPACE.COM>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>