Re: [openstack-dev] [nova] Consuming keystoneclient's Session object in novaclient
- Original Message - From: Joe Gordon joe.gord...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Thursday, May 8, 2014 4:54:31 PM Subject: Re: [openstack-dev] [nova] Consuming keystoneclient's Session object in novaclient On Wed, May 7, 2014 at 7:54 PM, Jamie Lennox jamielen...@redhat.com wrote: - Original Message - From: Monty Taylor mord...@inaugust.com To: openstack-dev@lists.openstack.org Sent: Thursday, May 8, 2014 8:22:21 AM Subject: Re: [openstack-dev] [nova] Consuming keystoneclient's Session object in novaclient On 05/07/2014 03:10 PM, Joe Gordon wrote: On Tue, May 6, 2014 at 3:22 PM, Jamie Lennox jamielen...@redhat.com mailto: jamielen...@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. So keystoneclient's session is designed to be passed around, rather than constructed individually by the clients, so that the same authentication mechanisms can be shared by multiple instances of a client. A made up, but not unrealistic example: auth = keystoneclient.auth.identity.v3.Password(auth_url=' http://keystone/v3 ', username='user', password='pass', ...) session = keystoneclient.session.Session(auth=auth, cacerts='path/to') glance = glanceclient.v1.Client(session) keystone = keystoneclient.v3.Client(session) nova = novaclient.v1.Client(session) This is why the dependency on keystoneclient falls onto the user (eg heat, horizon, OSC etc). Passing the session around will be the norm rather than an additional inconvenience. Having said
Re: [openstack-dev] [nova] Consuming keystoneclient's Session object in novaclient
On Wed, May 7, 2014 at 7:54 PM, Jamie Lennox jamielen...@redhat.com wrote: - Original Message - From: Monty Taylor mord...@inaugust.com To: openstack-dev@lists.openstack.org Sent: Thursday, May 8, 2014 8:22:21 AM Subject: Re: [openstack-dev] [nova] Consuming keystoneclient's Session object in novaclient On 05/07/2014 03:10 PM, Joe Gordon wrote: On Tue, May 6, 2014 at 3:22 PM, Jamie Lennox jamielen...@redhat.com mailto:jamielen...@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. So keystoneclient's session is designed to be passed around, rather than constructed individually by the clients, so that the same authentication mechanisms can be shared by multiple instances of a client. A made up, but not unrealistic example: auth = keystoneclient.auth.identity.v3.Password(auth_url=' http://keystone/v3', username='user', password='pass', ...) session = keystoneclient.session.Session(auth=auth, cacerts='path/to') glance = glanceclient.v1.Client(session) keystone = keystoneclient.v3.Client(session) nova = novaclient.v1.Client(session) This is why the dependency on keystoneclient falls onto the user (eg heat, horizon, OSC etc). Passing the session around will be the norm rather than an additional inconvenience. Having said that the novaclient CLI is a consumer of the novaclient library and so there is going to be a dependence there eventually. We can rip out the existing
Re: [openstack-dev] [nova] Consuming keystoneclient's Session object in novaclient
Is there a bp to coordinate work on aligning all clients to the Session object? Having a consistent implementation would make users and developers life so much easier – not to mention QA :) andrea From: Joe Gordon [mailto:joe.gord...@gmail.com] Sent: 08 May 2014 21:55 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] Consuming keystoneclient's Session object in novaclient On Wed, May 7, 2014 at 7:54 PM, Jamie Lennox jamielen...@redhat.com mailto:jamielen...@redhat.com wrote: - Original Message - From: Monty Taylor mord...@inaugust.com mailto:mord...@inaugust.com To: openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Sent: Thursday, May 8, 2014 8:22:21 AM Subject: Re: [openstack-dev] [nova] Consuming keystoneclient's Session object in novaclient On 05/07/2014 03:10 PM, Joe Gordon wrote: On Tue, May 6, 2014 at 3:22 PM, Jamie Lennox jamielen...@redhat.com mailto:jamielen...@redhat.com mailto:jamielen...@redhat.com mailto:jamielen...@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. So keystoneclient's session is designed to be passed around, rather than constructed individually by the clients, so that the same authentication mechanisms can be shared by multiple instances of a client. A made up, but not unrealistic example: auth = keystoneclient.auth.identity.v3.Password(auth_url='http://keystone/v3', username='user', password='pass', ...) session
Re: [openstack-dev] [nova] Consuming keystoneclient's Session object in novaclient
On May 6, 2014, at 15:22, Jamie Lennox jamielen...@redhat.com wrote: If there are concerns with this process please respond here and/or on the review. This sounds like it would be a fix for a bug affecting clients that I was looking at recently: https://bugs.launchpad.net/python-novaclient/+bug/1154809 If so, maybe we can add a note in the bug linking to this work. signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Consuming keystoneclient's Session object in novaclient
On Tue, May 6, 2014 at 3:22 PM, Jamie Lennox jamielen...@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Consuming keystoneclient's Session object in novaclient
On 05/07/2014 03:10 PM, Joe Gordon wrote: On Tue, May 6, 2014 at 3:22 PM, Jamie Lennox jamielen...@redhat.com mailto:jamielen...@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@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Consuming keystoneclient's Session object in novaclient
- Original Message - From: Monty Taylor mord...@inaugust.com To: openstack-dev@lists.openstack.org Sent: Thursday, May 8, 2014 8:22:21 AM Subject: Re: [openstack-dev] [nova] Consuming keystoneclient's Session object in novaclient On 05/07/2014 03:10 PM, Joe Gordon wrote: On Tue, May 6, 2014 at 3:22 PM, Jamie Lennox jamielen...@redhat.com mailto:jamielen...@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. So keystoneclient's session is designed to be passed around, rather than constructed individually by the clients, so that the same authentication mechanisms can be shared by multiple instances of a client. A made up, but not unrealistic example: auth = keystoneclient.auth.identity.v3.Password(auth_url='http://keystone/v3', username='user', password='pass', ...) session = keystoneclient.session.Session(auth=auth, cacerts='path/to') glance = glanceclient.v1.Client(session) keystone = keystoneclient.v3.Client(session) nova = novaclient.v1.Client(session) This is why the dependency on keystoneclient falls onto the user (eg heat, horizon, OSC etc). Passing the session around will be the norm rather than an additional inconvenience. Having said that the novaclient CLI is a consumer of the novaclient library and so there is going to be a dependence there eventually. We can rip out the existing transport logic of the HTTPClient such that it constructs a session object for us, but it essentially comes down to what sort of behaviour change is allowed. Scanning
[openstack-dev] [nova] Consuming keystoneclient's Session object in novaclient
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). If there are concerns with this process please respond here and/or on the review. Thanks, Jamie ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
