Re: [openstack-dev] [cinder] running afoul of Service.__repr__() during client.serivces.list()
Am Mittwoch, den 21.09.2016, 15:49 +0200 schrieb Michał Dulko:
>
> On 09/21/2016 03:32 PM, Konstanski, Carlos P wrote:
> >
> > 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 "" %
> > > > > 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.00',
> > > > > 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.00',
> > > > > 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] ?
> I've meant Gerrit review page linked above under [1]:
> > https://review.openstack.org/#/c/308
Ah there it is. (my email client makes links invisible, sorry.) No, unrelated.
Similar but I'm dealing with the Service class, not the Volume class. And fixing
the __repr__ method isn't going to help in my case. I need the actual data, not
a barely-unique summary of the data. Review coming as soon as I figure out the
mechanics.
__
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
Re: [openstack-dev] [cinder] running afoul of Service.__repr__() during client.serivces.list()
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 "" %
> > > 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.00', 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.00',
> > > 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
Re: [openstack-dev] [cinder] running afoul of Service.__repr__() during client.serivces.list()
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 "" % 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.00', 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.00',
> 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
__
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
[openstack-dev] [cinder] running afoul of Service.__repr__() during client.serivces.list()
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 "" % 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.00', 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.00',
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
