[openstack-dev] [all] cross project communication: Return request-id to caller

Doug Hellmann doug at doughellmann.com
Tue Jul 28 13:48:25 UTC 2015


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-iterator-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:

  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



More information about the OpenStack-dev mailing list