Bug 1306356 - [TEXT] engine-setup should tell user to look at engine tasks tabs for info about running tasks on upgrade
Summary: [TEXT] engine-setup should tell user to look at engine tasks tabs for info ab...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: Setup.Engine
Version: 3.6.3.1
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: ---
Assignee: Yedidyah Bar David
QA Contact: Aleksei Slaikovskii
URL:
Whiteboard:
Depends On: 1320498
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-02-10 16:21 UTC by sefi litmanovich
Modified: 2022-02-25 08:24 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-06-25 07:27:35 UTC
oVirt Team: Integration
Embargoed:


Attachments (Terms of Use)
engine-setup log (470.26 KB, text/plain)
2016-02-10 16:21 UTC, sefi litmanovich
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHV-44905 0 None None None 2022-02-25 08:24:43 UTC

Description sefi litmanovich 2016-02-10 16:21:11 UTC
Created attachment 1122842 [details]
engine-setup log

Description of problem:

Recently a patch was introduced to provide user with information regarding async tasks still running in the system that prevent user from going through the upgrade, see https://bugzilla.redhat.com/show_bug.cgi?id=1290528.

In terms of usability I think that the result is not idle.
e.g. I tried to upgrade my setup and got the following message:

          The following system tasks have been found running in the system:
          Task ID:           5c4cfa8f-175a-4786-9381-1aa274416acb
          Task Name:         Unknown                       
          Task Description:  Unknown                       
          Started at:        30
          DC Name:           golden_env_mixed              
          The following commands have been found running in the system:
          The following compensations have been found running in the system:

This information is really not very sufficient. Of course I asked around and then looked in setup log for the task ID, which resulted with some information (action type, which is an enum from engine java code) and a hint leading me to guess that my problem was due to difference between a VM's configured and actual timezone. If I wasn't a QE guy for Ovirt that specifically tested timezone configuration recently, no way that I would deduct that this was the problem

To me it doesn't make sense that the information regarding this task exist and can practically be pin pointed to the user, but still I get 'Unknown' instead.
I would suggest finding a solution to provide user with full task description, or at least some sort of hint for what should be he's next step in handling the issue.
Needless to say that if I were new to the product I would be utterly clueless in front of such message. 


Version-Release number of selected component (if applicable):
upgrade from rhevm-3.6.3-0.1.el6.noarch to rhevm-3.6.3.1-0.1.el6.noarch


Steps to Reproduce:
1. Have a 3.6.3-0.1.el6.noarch env.
2. Create a vm with some rhel os and guest-tools on it.
3. If guest agent reports a different time zone than configured, keep it that way, if they are the same, change configuration of the vm in engine and restart the vm, so engine will report the difference.
4. attempt to upgrade engine to rhevm-3.6.3.1-0.1.el6.noarch

Actual results:
During setup the following message appear and eventually you are forced to cancel the upgrade.

          The following system tasks have been found running in the system:
          Task ID:           5c4cfa8f-175a-4786-9381-1aa274416acb
          Task Name:         Unknown                       
          Task Description:  Unknown                       
          Started at:        30
          DC Name:           golden_env_mixed              
          The following commands have been found running in the system:
          The following compensations have been found running in the system:

Expected results:
A more informative message that helps user solve his blocking issue.

Additional info:

Comment 1 Yaniv Lavi 2016-02-17 08:34:00 UTC
We need to decide on how to tell the user\engine to resolve issues like this.

Comment 2 Yedidyah Bar David 2016-02-17 09:01:24 UTC
There are two issues here:

1. How to give the user more meaningful information in engine-setup.
See also bug 1240940 for this. If (why?) we do not want to expose this information using the existing enum, might use other means? api/sdk?
Might not be needed at all if (2.) below is enough.

2. How to let the user actually handle/monitor pending tasks.
We have a Tasks tab in the web admin.
Do all of them appear there?
Do we have good means to show progress?
Do we allow killing/removing/rolling back dead/non-critical/etc ones?

For some of the above we might have/need open BZs, not sure.

Yaniv - how should we continue?

Comment 3 Yaniv Lavi 2016-02-21 11:20:16 UTC
(In reply to Yedidyah Bar David from comment #2)
> There are two issues here:
> 
> 1. How to give the user more meaningful information in engine-setup.
> See also bug 1240940 for this. If (why?) we do not want to expose this
> information using the existing enum, might use other means? api/sdk?
> Might not be needed at all if (2.) below is enough.
> 
> 2. How to let the user actually handle/monitor pending tasks.
> We have a Tasks tab in the web admin.
> Do all of them appear there?
> Do we have good means to show progress?
> Do we allow killing/removing/rolling back dead/non-critical/etc ones?
> 
> For some of the above we might have/need open BZs, not sure.
> 
> Yaniv - how should we continue?

I am less concerned about what tasks are running and more concerned about user being stuck for a unknown amount of time on a unknown task. We should make it clear to the use on what to do to resolve issues, if we can.
I would consult with infra what they expect the user to do and what he needs to do if a task is stuck.

Comment 4 Yedidyah Bar David 2016-02-21 11:26:24 UTC
(In reply to Yaniv Dary from comment #3)
> I am less concerned about what tasks are running and more concerned about
> user being stuck for a unknown amount of time on a unknown task. We should
> make it clear to the use on what to do to resolve issues, if we can.
> I would consult with infra what they expect the user to do and what he needs
> to do if a task is stuck.

I wrote my above message after briefly discussing this with Oved.

He said users should use the existing Tasks tab.

Sefi - Can you please reproduce and check if you see there a task?

Comment 5 sefi litmanovich 2016-03-20 16:03:40 UTC
Sorry for the late reply.

I tried to re produce the issue with latest 'rhevm-3.6.4-0.1.el6.noarch'.
I made sure that TZ configuration differs from actual TZ setting on a rhel 7.2 vm with ovirt-guest-agent reporting TZ.
I get the exclamation mark on the vm.
No task is shown in task tab.
The difference is, that this time when tried to upgrade (engine-setup, although no new version is applied, let me know if that's a different flow and I'll do an "actual" upgrade), and setup did not report any running task interrupting the setup.

let me know what is our next step here.

Comment 6 Yedidyah Bar David 2016-03-21 14:20:48 UTC
No idea.

Attached log has:

2016-02-10 16:45:51 DEBUG otopi.ovirt_engine_setup.engine_common.database database.execute:171 Database: 'None', Statement: '
                select
                async_tasks.action_type,
                async_tasks.task_id,
                async_tasks.started_at,
                storage_pool.name
                from async_tasks, storage_pool
                where async_tasks.storage_pool_id = storage_pool.id
            ', args: {}
2016-02-10 16:45:51 DEBUG otopi.ovirt_engine_setup.engine_common.database database.execute:176 Creating own connection
2016-02-10 16:45:51 DEBUG otopi.ovirt_engine_setup.engine_common.database database.execute:221 Result: [{'started_at': datetime.datetime(2016, 2, 9, 14, 18, 58, 548000, tzinfo=<psycopg2.tz.FixedOffsetTimezone object at 0x2c65e10>), 'task_id': '5c4cfa8f-175a-4786-9381-1aa274416acb', 'action_type': 44, 'name': 'golden_env_mixed'}]

Oved - any reliable way to reproduce (cause a task of this type to be started, preferably in a way that will cause it to take a long time)?

Comment 7 Oved Ourfali 2016-03-21 14:24:02 UTC
You want a task that is "unknown" to the setup?
You can either hack the DB, or run one that you know is unknown and takes a lot of time (storage operation I guess).

Comment 8 Yedidyah Bar David 2016-03-21 14:31:13 UTC
(In reply to Oved Ourfali from comment #7)
> You want a task that is "unknown" to the setup?
> You can either hack the DB, or run one that you know is unknown and takes a
> lot of time (storage operation I guess).

Since this bug was opened about type 44, I am asking about it.

Of course it will be nice if we can test that all tasks that have a reasonable chance to take more than a few seconds, will appear in the Tasks tab, but let's start with current case. What's 44? How to cause starting it?

Comment 9 Yedidyah Bar David 2016-03-23 11:09:09 UTC
Sefi is currently handling 44 with Arik Hadas.

Following a discussion with Oved:

Long running tasks should appear in the Tasks tab, and engine-setup should tell user to look there for more info.

I now opened bug 1320498 to require that.

Comment 10 Sandro Bonazzola 2016-05-02 10:06:02 UTC
Moving from 4.0 alpha to 4.0 beta since 4.0 alpha has been already released and bug is not ON_QA.

Comment 11 Yaniv Lavi 2016-05-23 13:20:44 UTC
oVirt 4.0 beta has been released, moving to RC milestone.

Comment 12 Yaniv Lavi 2016-05-23 13:24:01 UTC
oVirt 4.0 beta has been released, moving to RC milestone.

Comment 13 Yaniv Lavi 2018-06-25 07:27:35 UTC
Closing old bugs.
Please reopen if still relevant.
Patches are welcomed.


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