Hi Devs, This change is not backward compatible and to do not break OpenStack services which are using cinder-client, we need to first make provision in these consumer services to handle cinder-client return type change. To make this cinder-client change backward compatible we need to do changes in consumers of cinder-client like patch : https://review.openstack.org/#/c/152820/
Also for backward compatibility can we make changes suggested by Gary W. Smith on cinder-spec : https://review.openstack.org/#/c/132161/6/. As per his suggestion we need to add one new optional kwarg 'return_req_id' in cinder-client api methods, when it is 'True' cinder-client will returns the tuple, but when False (the default) it returns the current value (i.e.- only response body). For example cinder-client 'get' method will look like - def _get(self, url, response_key=None, return_req_id=False): resp, body = self.api.client.get(url) if response_key: body = self.resource_class(self, body[response_key], loaded=True) else: body = self.resource_class(self, body, loaded=True) if return_req_id: # return tuple containing headers and body return (resp.headers, body) return body If we want headers from cinder-client then we need to pass kwarg 'return_req_id' as True from caller. For example from nova we need to call cinder-client get method as - resp_header, volume = cinderclient(context).volumes.get(volume_id, return_req_id=True) With this optional kwarg 'return_req_id' approach we do not need to make changes in services which are using cinder-client. It will be backward compatible change. Could you please give your suggestion on this approach. Thanks, Abhishek From: Joe Gordon [mailto:joe.gord...@gmail.com] Sent: 05 February 2015 22:50 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [python-cinderclient] Return request ID to caller On Wed, Feb 4, 2015 at 11:23 PM, Malawade, Abhijeet <abhijeet.malaw...@nttdata.com<mailto:abhijeet.malaw...@nttdata.com>> wrote: Hi, I have submitted patch for cinder-client [1] to 'Return tuple containing header and body from client' instead of just response. Also cinder spec for the same is under review [2]. This change will break OpenStack services which are using cinder-client. To do not break services which are using cinder-client, we need to first make changes in those projects to check return type of cinder-client. We are working on doing cinder-client return type check changes in OpenStack services like nova, glance_store, heat, trove, manila etc. We have already submitted patch for same against nova : https://review.openstack.org/#/c/152820/ [1] https://review.openstack.org/#/c/152075/ [2] https://review.openstack.org/#/c/132161/ This sounds like a backwards incompatible change to the python client, that will break downstream consumers of python-cinderclient. This change should be done in a way that allows us to deprecate the old usage without breaking it right away. I want to seek early feedback from the community members on the above patches, so please give your thoughts on the same. Thanks, Abhijeet Malawade ______________________________________________________________________ Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ______________________________________________________________________ Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
