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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
