----- Original Message ----- > From: "Joe Gordon" <joe.gord...@gmail.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@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 < jamielen...@redhat.com > > wrote: > > > > > > ----- Original Message ----- > > From: "Monty Taylor" < mord...@inaugust.com > > > To: openstack-dev@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 < jamielen...@redhat.com > > > <mailto: jamielen...@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@lists.openstack.org > > > <mailto: OpenStack-dev@lists.openstack.org > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > > > > > > > _______________________________________________ > > > OpenStack-dev mailing list > > > OpenStack-dev@lists.openstack.org > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
