[openstack-dev] [cinder] running afoul of Service.__repr__() during client.serivces.list()

Michał Dulko michal.dulko at intel.com
Wed Sep 21 13:07:58 UTC 2016


On 09/21/2016 02:32 AM, Konstanski, Carlos P wrote:
> Am Dienstag, den 20.09.2016, 15:31 -0600 schrieb Konstanski, Carlos P:
>> I am currently using python-cinderclient version 1.5.0, though the code in
>> question is still in master.
>>
>> When calling client.services.list() I get this result: "AttributeError:
>> service"
>>
>> The execution path of client.services.list() eventually leads to this method
>> in
>> cinderclient/v2/services.py:24:
>>
>> def __repr__(self):                                                          
>>  
>>     return "<Service: %s>" % self.service                                    
>>   
>>
>> which in turn triggers a call to Resouce.__getattr__() in
>> cinderclient/openstack/common/apiclient/base.py:456.
>>
>> This custom getter will never find an attribute called service because a
>> Service
>> instance looks something like the following:
>>
>> {u'status': u'enabled', u'binary': u'cinder-scheduler', u'zone': u'nova',
>> u'host': u'dev01', u'updated_at': u'2016-09-20T21:16:00.000000', u'state':
>> u'up', u'disabled_reason': None}
>>
>> So it returns the string "AttributeError: service".
>>
>> One way or another a fix is warranted, and I am ready, willing and able to
>> provide the fix. But first I want to find out more about the bigger picture.
>> could  it be that this __repr__() method actually correct, but the code that
>> populates my service instance is faulty? This could easily be the case if the
>> dict that feeds the Service class were to look like the following (for
>> example):
>>
>> {u'service': {u'status': u'enabled', u'binary': u'cinder-scheduler', u'zone':
>> u'nova', u'host': u'dev01', u'updated_at': u'2016-09-20T21:16:00.000000',
>> u'state': u'up', u'disabled_reason': None}}
>>
>> Somehow I doubt it; why hide all the useful attributes in a dict under a
>> single
>> parent attribute? But I'm new to cinder and I don't know the rules. I'm not
>> here
>> to question your methods.
>>
>> Or am I just using it wrong? This code has survived for a long time, and
>> certainly someone would have noticed a problem by now. But it seems pretty
>> straightforward. How many ways are there to prepare a call to
>> client.services.list()? I get a Client instance, call authenticate() for fun,
>> and then call client.services.list(). Not a lot going on here.
>>
>> I'll get to work on a patch when I figure out what it is supposed to do, if it
>> is not already doing it.
>>
>> Sincerely,
>> Carlos Konstanski
> I guess the question I should be asking is this: Manager._list() (in
> cinderclient/base.py) returns a list of printable representations of objects,
> not a list of the objects themselves. Hopefully there's a more useful method
> that returns a list of actual objects, or at least a JSON representation. If I
> can't find such a method then I'll be back, or I'll put up a review to add one.
>
> Carlos

Is bug being addressed in review [1] somehow related? If so, there's
some discussion on solutions going.

[1] https://review.openstack.org/#/c/308475



More information about the OpenStack-dev mailing list