Open Stack

On Thu, Feb 5, 2015 at 11:24 PM, Kekane, Abhishek <
Abhishek.Kekane at 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.gordon0 at 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.Malawade at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> 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/20150206/1ebc27c7/attachment.html>