Open Stack

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

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