Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1412868 - UI crashes when showing "system information" if a service has a timestamp of "null"
Summary: UI crashes when showing "system information" if a service has a timestamp of ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-cinderclient
Version: 9.0 (Mitaka)
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: 9.0 (Mitaka)
Assignee: Eric Harney
QA Contact: Ola Pavlenko
URL:
Whiteboard:
Depends On: 1414806
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-13 02:06 UTC by Anil Dhingra
Modified: 2020-04-15 15:05 UTC (History)
8 users (show)

Fixed In Version: python-cinderclient-1.6.0-2.el7ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1414806 (view as bug list)
Environment:
Last Closed: 2017-03-09 17:54:00 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1594308 0 None None None 2017-01-19 14:02:09 UTC
OpenStack gerrit 331596 0 None None None 2017-01-19 14:02:58 UTC
Red Hat Product Errata RHBA-2017:0478 0 normal SHIPPED_LIVE openstack-cinder bug fix advisory 2017-03-09 22:53:43 UTC

Description Anil Dhingra 2017-01-13 02:06:11 UTC
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:

Comment 3 Radomir Dopieralski 2017-01-13 13:44:55 UTC
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.

Comment 4 Radomir Dopieralski 2017-01-13 16:14:01 UTC
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.

Comment 12 Radomir Dopieralski 2017-03-02 13:02:19 UTC
I can see the problematic line of code has been fixed.

Comment 14 errata-xmlrpc 2017-03-09 17:54:00 UTC
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


Note You need to log in before you can comment on or make changes to this bug.