On Tue, May 6, 2014 at 3:22 PM, Jamie Lennox <[email protected]> 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. > > > If there are concerns with this process please respond here and/or on the > review. > > Thanks, > > Jamie > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
