Hide Forgot
Description of problem: If there is a service configured in openstack with a timestamp of "null", the UI crashes when a user click on "system information". Obviously the dashboard cannot handle the null value of service timestamp. Version-Release number of selected component (if applicable): Redhat OpenStack 9 Platform How reproducible: Repeatedly and verified. Steps to Reproduce: 1.Example: If there is a cinder service configured, that did not start, and has no "updated_at" timestamp, the value of this timestamp is null and breaks the UI. If you run "cinter service-list", you can check this updated_at timestamp. This value is getting retrieved in the overview of the "system information" UI, and causes the UI to crash if it is "null" for any service shown there. I hit this issue when reconfiguring my services, and one of the services was created but not started for a first time. A workaround is to simply manually start/stop the service using the CLI. When doing this a timestamp is created and the UI can work with the value now. Even though there is a workaround, it was time consuming to find the root cause, as the error message in the UI does not contain any information about the root cause. 2.service configuration containing a null value: Cinder service-list showed the following output: hostgroup-dc1@netapp1 is enabled but the service did not start properly for some reason. This can happen due to multiple reasons, but it should never break the UI. +------------------+----------------------------+------+----------+-------+----------------------------+-----------------+ | Binary | Host | Zone | Status | State | Updated_at | Disabled Reason | +------------------+----------------------------+------+----------+-------+----------------------------+-----------------+ | cinder-scheduler | hostgroup-dc1 | dc1 | enabled | up | 2016-11-14T08:38:51.000000 | - | | cinder-scheduler | hostgroup-dc2 | dc2 | enabled | up | 2016-11-14T08:38:50.000000 | - | | cinder-volume | hostgroup-dc1@netapp | dc1 | enabled | down | 2016-11-08T14:44:11.000000 | - | | cinder-volume | hostgroup-dc1@netapp1 | dc1 | enabled | down | - | - | | cinder-volume | hostgroup-dc1@tripleo_ceph | dc1 | enabled | down | 2016-11-14T08:38:56.000000 | - | | cinder-volume | hostgroup-dc2@netapp | dc2 | enabled | down | 2016-11-08T14:44:32.000000 | - | | cinder-volume | hostgroup-dc2@netapp2 | dc2 | enabled | up | 2016-11-14T08:38:49.000000 | - | | cinder-volume | hostgroup-dc2@tripleo_ceph | dc2 | enabled | up | 2016-11-08T14:44:45.000000 | - | | cinder-volume | hostgroup@tripleo_ceph1 | dc1 | enabled | up | 2016-11-14T08:38:55.000000 | - | | cinder-volume | hostgroup@tripleo_ceph2 | dc2 | enabled | up | 2016-11-14T08:38:57.000000 | - | +------------------+----------------------------+------+----------+-------+----------------------------+-----------------+ 3. Actual results: Horizon not able to handle null values in variables. Expected results: Horizon should be able to handle null values in variables. Additional info:
I couldn't reproduce this bug. With an null timestamp, my horizon just displays "-" in that column. I'm afraid that the cause for this crash may be actually different. It would be helpful to have any logs or traceback from the crash.
I think I managed to reproduce the error, but the problem is actually not in Horizon, but in python-cinderclient: ... File "/usr/lib/python2.7/site-packages/horizon/tables/base.py", line 381, in get_data data = self.get_raw_data(datum) File "/usr/lib/python2.7/site-packages/horizon/tables/base.py", line 363, in get_raw_data "%(obj)s.") % {'attr': self.transform, 'obj': datum} File "/usr/lib/python2.7/site-packages/django/utils/functional.py", line 178, in __mod__ return six.text_type(self) % rhs File "/usr/lib/python2.7/site-packages/cinderclient/v2/services.py", line 25, in __repr__ return "<Service: %s>" % self.service File "/usr/lib/python2.7/site-packages/cinderclient/openstack/common/apiclient/base.py", line 505, in __getattr__ raise AttributeError(k) TemplateSyntaxError: service It looks like it's referencing a non-existing attribute "service" on the service object.
I can see the problematic line of code has been fixed.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2017-0478.html