Bug 1289199 - all events appear with the same name (the provider name) in the timeline
all events appear with the same name (the provider name) in the timeline
Status: CLOSED ERRATA
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: UI - OPS (Show other bugs)
5.5.0
x86_64 Linux
unspecified Severity urgent
: GA
: 5.5.2
Assigned To: Daniel Korn
Dafna Ron
container
: ZStream
Depends On: 1288134 1294374 1295430
Blocks: 1300376
  Show dependency treegraph
 
Reported: 2015-12-07 11:22 EST by John Prause
Modified: 2016-02-10 10:22 EST (History)
13 users (show)

See Also:
Fixed In Version: 5.5.2.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1288134
: 1300376 (view as bug list)
Environment:
Last Closed: 2016-02-10 10:22:32 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
screen shot (144.60 KB, image/png)
2016-01-19 09:09 EST, Dafna Ron
no flags Details

  None (edit)
Description John Prause 2015-12-07 11:22:02 EST
+++ This bug was initially created as a clone of Bug #1288134 +++

Description of problem:

On the monitorinng ->timeline, all of the containers and pods have the name of the provider instead of their own name. 

Version-Release number of selected component (if applicable):

cfme-5.5.0.13-1.el7cf.x86_64

How reproducible:

100%

Steps to Reproduce:
1. navigate to provider -> select provider -> monitoring -> timeline 
2. navigate to pods -> select a pod -> monitoring -> timeline
3. navigate to containers -> select a container -> timeline

Actual results:

All of the objects that appear under the timeline have the same name which is the provider. 

Expected results:

we should see the object's actual name 

Additional info: logs and screenshots

--- Additional comment from Daniel Korn on 2015-12-07 08:14 EST ---



--- Additional comment from Daniel Korn on 2015-12-07 08:14 EST ---



--- Additional comment from Daniel Korn on 2015-12-07 08:15:55 EST ---

To maintain consistency with other providers, the event should display the *entity name* and not the provider or event type. see attached screenshots for infra provider.

Though it makes sense to show the event type when the event is directly related to the entity you look at (for example CONTAINER_STARTED when you look at a container), IMHO it is not the right choice when the event is related to an inner entity (container when you look at the pod's timeline).

--- Additional comment from Daniel Korn on 2015-12-07 10:53:00 EST ---

proposed fix: https://github.com/ManageIQ/manageiq/pull/5731
Comment 4 Dafna Ron 2016-01-19 09:08:56 EST
Although no longer the provider name, the containers/pods still appear with the same name instead of having the unique name given by the system like in cli: 

jenkins-1-vacbn   0/1       Terminating   0          17m
jenkins-1-wihy5   0/1       Terminating   0          17m
jenkins-1-wqfvq   0/1       Terminating   0          17m
jenkins-1-x5u65   0/1       Terminating   0          17m
jenkins-1-xuzjc   0/1       Terminating   0          20m
jenkins-1-y1nz4   0/1       Terminating   0          17m
jenkins-1-ydcna   0/1       Terminating   0          17m

11m         11m        1         openshift-node-dafna.novalocal      Node                                                        TerminatingEvictedPod    {controllermanager }                            Node openshift-node-dafna.novalocal event: Pod jenkins-1-y1gc1 has exceeded the grace period for deletion after being evicted from Node "openshift-node-dafna.novalocal" and is being force killed

will attach the screen shot
Comment 5 Dafna Ron 2016-01-19 09:09 EST
Created attachment 1116183 [details]
screen shot
Comment 6 Dafna Ron 2016-01-20 10:25:26 EST
After speaking to Daniel and giving it some thought, we believe that the pods appearing with cut names is a different bug. 
This bug is verified and I will open a new bug for the cut names. 
moving to verified for cfme-5.5.2.1-1.el7cf.x86_64
Comment 7 errata-xmlrpc 2016-02-10 10:22:32 EST
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://access.redhat.com/errata/RHBA-2016:0159

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