On Thu, Feb 5, 2015 at 11:24 PM, Kekane, Abhishek < abhishek.kek...@nttdata.com> wrote:
> 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. > Maintaining backwards compatibility is very important. Making return_req_id optional sounds like a good solution going forward. > > > 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> 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://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 > >
__________________________________________________________________________ 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
