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()
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/308475 > 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 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()
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 __ 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