<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 6, 2014 at 3:22 PM, Jamie Lennox <span dir="ltr"><<a href="mailto:jamielennox@redhat.com" target="_blank">jamielennox@redhat.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">All,<br>
<br>
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.<br>


<br>
<br>
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.<br>


<br>
It offers:<br>
 - a single place for updates to transport (eg fixing TLS or other transport issues in one place)<br>
 - a way for all clients to immediately support the full range of keystone's authentication including v3 auth, SAML, kerberos etc<br>
 - a common place to handle version discovery such that we support multiple version endpoints from the same service catalog endpoint.<br>
<br>
For information of how to interact with a session you can see: <a href="http://www.jamielennox.net/blog/2014/02/24/client-session-objects/" target="_blank">http://www.jamielennox.net/blog/2014/02/24/client-session-objects/</a> 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.<br>


<br>
<br>
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.<br>


<br>
The review showing these changes is here: <a href="https://review.openstack.org/#/c/85920" target="_blank">https://review.openstack.org/#/c/85920</a><br>
<br>
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: <a href="https://blueprints.launchpad.net/python-novaclient/+spec/httpretty-testing" target="_blank">https://blueprints.launchpad.net/python-novaclient/+spec/httpretty-testing</a><br>


<br>
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.<br>
<br>
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).<br>

</blockquote><div><br></div><div>Can we make novaclient use keystoneclient's session by default? And just add this to requirements.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<br>
<br>
If there are concerns with this process please respond here and/or on the review. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Thanks,<br>
<br>
Jamie<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div>