Open Stack

Hi Devs,

I have modified the cross-project specs for request-id based on this analysis and submitted same for review.
Please refer, https://review.openstack.org/#/c/156508/17/specs/return-request-id.rst and give your valuable feedback on the same.

Thank you in advance.

Abhishek Kekane

-----Original Message-----
From: Gorka Eguileor [mailto:geguileo at redhat.com] 
Sent: 29 July 2015 15:07
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] cross project communication: Return request-id to caller

On Tue, Jul 28, 2015 at 09:48:25AM -0400, Doug Hellmann wrote:
> Excerpts from Gorka Eguileor's message of 2015-07-28 10:37:42 +0200:
> > On Fri, Jul 24, 2015 at 10:08:45AM -0400, Doug Hellmann wrote:
> > > Excerpts from Kekane, Abhishek's message of 2015-07-24 06:33:00 +0000:
> > > > Hi Devs,
> > > > 
> > > > X-Openstack-Request-Id. We have analysed python-cinderclient, python-glanceclient, python-novaclient, python-keystoneclient and python-neutronclient to check the return types.
> > > > 
> > > > There are 9 ways return values are returned from python clients:
> > > > 1. List
> > > > 2. Dict
> > > > 3. Resource class object
> > > > 4. None
> > > > 5. Tuple
> > > > 6. Exception
> > > > 7. Boolean (True/False, for keystoneclient) 8. Generator (for 
> > > > list api's in glanceclient) 9. String (for novaclient)
> > > > 
> > > > Out of 9 we have solution for all return types except generator.
> > > > In case of glance-client list api's are returning generator which is immutable. So it is not possible to return request-id in this case, which is a blocker for adopting the solution.
> > > > 
> > > > I have added detail analysis for above return types in etherpad [2] as solution #3.
> > > > 
> > > > If you have any suggestion in case of generation type then please let me know.
> > > 
> > > It should be possible to create a new class to wrap the existing 
> > > generator and implement the iterator protocol [3].
> > > 
> > > [3] 
> > > https://docs.python.org/2/reference/expressions.html#generator-ite
> > > rator-methods
> > > 
> > > Doug
> > > 
> > 
> > Unless I'm missing something I think we wouldn't even need to create 
> > a new class that implements the iterator protocol, we can just 
> > return a generator that generates from the other one.
> > 
> > For example, for each of the requests, if we get the generator in 
> > variable *result* that returns dictionaries and we want to add 
> > *headers* to each dictionary:
> > 
> > return (DictWithHeaders(resource, headers) for resource in result)
> > 
> > Wouldn't that work?
> 
> That would work, but it wouldn't be consistent with the way I read [2] 
> as describing how the other methods are being updated.
> 
> For example, a method that now returns a list() will return a 
> ListWithHeaders(), and only that returned object will have the 
> headers, not its contents. A caller could do:

You are right, it wouldn't be consistent with other methods, and that's not good. So the new iterator class wrapper seems to be the way to go.


Gorka.

> 
>   response = client.some_method_returning_a_list()
>   print reponse.headers
> 
> but could not do
> 
>   print response[0].headers
> 
> and get the same values.
> 
> Creating a GeneratorWithHeaders class mirrors that behavior for 
> methods that return generators instead of lists.
> 
> Doug
> 
> > > > [2] https://etherpad.openstack.org/p/request-id
> 
> ______________________________________________________________________
> ____ 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

__________________________________________________________________________
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.