Open Stack

----- Original Message -----
> From: "Joe Gordon" <joe.gordon0 at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
> Sent: Thursday, May 8, 2014 4:54:31 PM
> Subject: Re: [openstack-dev] [nova] Consuming keystoneclient's Session object in novaclient
> 
> 
> 
> 
> On Wed, May 7, 2014 at 7:54 PM, Jamie Lennox < jamielennox at redhat.com >
> wrote:
> 
> 
> 
> 
> 
> ----- 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.
> 
> 
> My question is why not make the novaclient CLI use the keystoneclient's
> session by default (but don't change the default behavior for the python
> library). We can still leave in the old logic in place so that python
> developers using python-novaclient (the library) have to opt-in to using
> keystoneclient's session object.

Oh, absolutely agreed. Once the library is able to take a session the CLI should use it exclusively.

> 
> 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.
> 
> Makes sense to me, I would add horizon into this list as well.
> 
> 
> 
> 
> 
> > > 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
> > 
> 
> _______________________________________________
> 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
>