Bug 1360182

Summary: improve clarity of "Force Stop. Task explicitly stopped." message
Product: [Red Hat Storage] Red Hat Storage Console Reporter: Martin Bukatovic <mbukatov>
Component: coreAssignee: Shubhendu Tripathi <shtripat>
Status: CLOSED ERRATA QA Contact: Martin Kudlej <mkudlej>
Severity: low Docs Contact:
Priority: unspecified    
Version: 2CC: julim, mkudlej, nthomas, sankarshan, shtripat, vsarmila
Target Milestone: ---   
Target Release: 2   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: rhscon-core-0.0.37-1.el7scon Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-08-23 19:58:05 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1353450    
Attachments:
Description Flags
screenshot 1: task details page after a timeout none

Description Martin Bukatovic 2016-07-26 07:44:25 UTC
Description of problem
======================

When RHSC 2.0 task is killed by console itself because of timeout, in a Task
Details page for the task, the message reporting this has the following format:

> Force Stop. Task: TASK_UID explicitly stopped.

This is the only information on the task detail page related to the
failure caused by the timeout.

The problem with the such error message is that it's not completely clear that:

* the task was killed by console itself (and not by a user or some other
  component)
* the reason for the force stop of the task is a timeout, the task took longer
  than expected

Version-Release
===============

rhscon-ceph-0.0.36-1.el7scon.x86_64
rhscon-core-selinux-0.0.36-1.el7scon.noarch
rhscon-core-0.0.36-1.el7scon.x86_64
rhscon-ui-0.0.50-1.el7scon.noarch

How reproducible
================

100%

Steps to Reproduce
==================

1. Install RHSC 2.0 following the documentation.
2. Start a task (eg. Initialize Node, Create Cluster) so that it will
   timeout.
3. Check the Task Details page when the task fails.

Actual results
==============

On the task detail page of the failed task, the last entry states:

> Force Stop. Task: a46cdd63-2f2e-403d-8cdc-ddb5c42fd506 explicitly stopped.

Expected results
================

On the task detail page of the failed task, the last entry states:

> Task a46cdd63-2f2e-403d-8cdc-ddb5c42fd506 has been killed after timeout

I'm not proposing a particular replacement, as I'm neither native speaker or
ui designer.

That said, It should be clear that:

* the task was killed/stopped by console itself
* console did this because of timeout

Comment 1 Martin Bukatovic 2016-07-26 07:46:53 UTC
Created attachment 1184086 [details]
screenshot 1: task details page after a timeout

Comment 2 Martin Bukatovic 2016-07-26 07:48:44 UTC
Could the design team propose suitable replacement for the current message here?

Comment 3 Shubhendu Tripathi 2016-07-27 03:49:36 UTC
I am changing the message as "Force Stop. Task: <id> explicitly stopped due to timeout."

Comment 5 Martin Bukatovic 2016-08-01 14:59:26 UTC
(In reply to Shubhendu Tripathi from comment #3)
> I am changing the message as "Force Stop. Task: <id> explicitly stopped due
> to timeout."

Since it seems that the format of the message has been decided and it looks ok,
I'm removing the needinfo flag.

Comment 6 Martin Kudlej 2016-08-03 11:39:44 UTC
Tested with
ceph-ansible-1.0.5-32.el7scon.noarch
ceph-installer-1.0.14-1.el7scon.noarch
rhscon-ceph-0.0.39-1.el7scon.x86_64
rhscon-core-0.0.39-1.el7scon.x86_64
rhscon-core-selinux-0.0.39-1.el7scon.noarch
rhscon-ui-0.0.51-1.el7scon.noarch
and task ID is missing in error message:
"Force Stop. Task explicitly stopped due to timeout."
-->ASSIGNED

Comment 7 Shubhendu Tripathi 2016-08-03 12:15:08 UTC
Martin, so the message comes from two different places in USM. In one place from where this got generated we dont have task id available and so not in the message.

Also this BZ was just to make message more clearer which was already existing.

This is actually not an issue should be verified as its as per the code in USM.

Comment 8 Martin Kudlej 2016-08-03 12:33:03 UTC
Closing as Verified after discussion.

Comment 10 errata-xmlrpc 2016-08-23 19:58:05 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://access.redhat.com/errata/RHEA-2016:1754