Open Stack

----- Original Message -----
> From: "Monty Taylor" <mordred at inaugust.com>
> To: openstack-dev at lists.openstack.org
> Sent: Thursday, May 8, 2014 8:22:21 AM
> Subject: Re: [openstack-dev] [nova] Consuming keystoneclient's Session object in novaclient
> 
> On 05/07/2014 03:10 PM, Joe Gordon wrote:
> >
> >
> >
> > On Tue, May 6, 2014 at 3:22 PM, Jamie Lennox <jamielennox at redhat.com
> > <mailto:jamielennox at redhat.com>> wrote:
> >
> >     All,
> >
> >     TL;DR: novaclient should be able to use the common transport/auth
> >     layers of keystoneclient. If it does there are going to be functions
> >     like client.authenticate() that won't operate the same way when a
> >     session object is passed. For most users who just use the CRUD
> >     operations there will be no difference.
> >
> >
> >     I'm hoping that at least some of the nova community has heard of the
> >     push for using keystoneclient's Session object across all the
> >     clients. For those unaware keystoneclient.session.Session is a
> >     common transport and authentication layer to remove the need for
> >     each python-*client having there own authentication configuration
> >     and disparate transport options.
> >
> >     It offers:
> >       - a single place for updates to transport (eg fixing TLS or other
> >     transport issues in one place)
> >       - a way for all clients to immediately support the full range of
> >     keystone's authentication including v3 auth, SAML, kerberos etc
> >       - a common place to handle version discovery such that we support
> >     multiple version endpoints from the same service catalog endpoint.
> >
> >     For information of how to interact with a session you can see:
> >     http://www.jamielennox.net/blog/2014/02/24/client-session-objects/
> >     This mentions the code is uncommitted however has since been
> >     committed with a few small details around parameter names being
> >     changed. The theory remains the same.
> >
> >
> >     To integrate this into novaclient means that if a session= object is
> >     passed then the standard HTTPClient code will be ignored in favour
> >     of using what was passed. This means that there are changes in the
> >     API of the client. In keystoneclient we have take the opinion that
> >     by passing a session object then you opt-in to the newer API and
> >     therefore accept that some functions are no longer available. For
> >     example client.authenticate() is no longer allowed because
> >     authentication is not the client's responsibility. It will have no
> >     impact on the standard novaclient CRUD operations and so be
> >     un-noticed by the vast majority of users.
> >
> >     The review showing these changes is here:
> >     https://review.openstack.org/#/c/85920
> >
> >     To enable this there are a series of test changes to mock client
> >     requests at the HTTP layer rather than in the client. This means
> >     that we can test that all client operations against the new and old
> >     client construction methods and ensure the same requests are being
> >     sent. The foundation of this to turn tests into fixtures can be
> >     found by following:
> >     https://blueprints.launchpad.net/python-novaclient/+spec/httpretty-testing
> >
> >     IMO making these tests into fixtures is a good idea anyway, however
> >     I am only pursuing it so that we can transition to using a common
> >     Session.
> >
> >     Regarding dependencies, novaclient will need a test-requirements.txt
> >     on keystoneclient so that it can construct Session objects to test
> >     with but it should not need a requirements.txt as the session object
> >     is constructed by the user of the client (eg openstackclient,
> >     horizon etc).
> >
> >
> > Can we make novaclient use keystoneclient's session by default? And just
> > add this to requirements.
> 
> ++
> 
> Once it's supported, I would think that someone wanting to use
> novaclient _without_ keystoneclient should be seen as the exception case
> and not the normal case.

So keystoneclient's session is designed to be passed around, rather than constructed individually by the clients, so that the same authentication mechanisms can be shared by multiple instances of a client. A made up, but not unrealistic example: 

auth = keystoneclient.auth.identity.v3.Password(auth_url='http://keystone/v3', username='user', password='pass', ...)
session = keystoneclient.session.Session(auth=auth, cacerts='path/to') 

glance = glanceclient.v1.Client(session) 
keystone = keystoneclient.v3.Client(session) 
nova = novaclient.v1.Client(session) 

This is why the dependency on keystoneclient falls onto the user (eg heat, horizon, OSC etc). Passing the session around will be the norm rather than an additional inconvenience. Having said that the novaclient CLI is a consumer of the novaclient library and so there is going to be a dependence there eventually.

We can rip out the existing transport logic of the HTTPClient such that it constructs a session object for us, but it essentially comes down to what sort of behaviour change is allowed. Scanning the existing HTTPClient code there are going to be subtle differences in:
 
- the service catalog logic
- when authentication is triggered
- keyring handling
- connection pooling
- the way the existing auth_system is handled.
- all the attributes saved on the client are no longer required.

None of these result in changes to user experience for standard use. However there are going to be consumers such as horizon and OSC who already deal with multiple clients that currently force set token data into the client rather than have each client authenticate itself again. They rely on specific behaviour that will possibly change. Most of these changes could be compensated for as we did in keystoneclient but it's not pretty.

So the theory is given that session is required to be passed anyway, passing a Session object is opting-in to new behaviour. When OSC changes to dealing with sessions the old hacks will be removed at the same time. But until then the existing behaviour will be maintained. When we are satisfied the changes work and we get more other client adoption then we deprecate passing username= etc to client.


> >     If there are concerns with this process please respond here and/or
> >     on the review.
> >
> >
> >
> >     Thanks,
> >
> >     Jamie
> >
> >     _______________________________________________
> >     OpenStack-dev mailing list
> >     OpenStack-dev at lists.openstack.org
> >     <mailto:OpenStack-dev at lists.openstack.org>
> >     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>