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