Open Stack

On Tue, May 6, 2014 at 3:22 PM, Jamie Lennox <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.


>
>
> 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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140507/ee971046/attachment.html>