Am Mittwoch, den 21.09.2016, 15:07 +0200 schrieb Michał Dulko:
> 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
This neophyte needs a bit of education. What is review [1] ?
In the meantime I have a potential fix. I'll see if some of my coworkers who
have put up patches in the past can help me figure out how it's done the
Openstack Way.
__________________________________________________________________________
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
