Open Stack

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.

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