Bug 1337965 - Accept node process is reported as done while Initialize node task is still running
Summary: Accept node process is reported as done while Initialize node task is still r...
Alias: None
Product: Red Hat Storage Console
Classification: Red Hat
Component: UI
Version: 2
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 2
Assignee: Soumya Deb
QA Contact: sds-qe-bugs
Depends On:
Blocks: Console-2-GA
TreeView+ depends on / blocked
Reported: 2016-05-20 14:52 UTC by Martin Bukatovic
Modified: 2016-07-15 16:09 UTC (History)
4 users (show)

Fixed In Version: rhscon-core-0.0.34-1.el7scon.x86_64 rhscon-ceph-0.0.33-1.el7scon.x86_64 rhscon-ui-0.0.47-1.el7scon.noarch
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2016-07-15 16:08:13 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1312404 0 unspecified CLOSED [API] tasks Accept Node finish before node is actually ready 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1338001 0 unspecified CLOSED there are 3 different implementations of Accept Host work flow, of which only one follows expected design 2021-02-22 00:41:40 UTC

Internal Links: 1312404 1338001

Description Martin Bukatovic 2016-05-20 14:52:36 UTC
Description of problem

When one triggers a accept host process, "Accept Node" task is created based
on this requrest first, and then after this task finishes with success, another
task "Initialize node" is started.

So far so good. The problem is that in some cases when user starts accept host
task, the success is reported immediately (based on the status of the "Accept
Node" task), without taking "Initialize node" task into account. This may lead
the user into false belief that the machine has been accepted properly while
the 2nd task (which actually configures the machine) is still running.





How reproducible

100 %

Steps to Reproduce

1. Install RHSC 2.0 following the documentation, make sure you have few nodes
   ready to be accepted later.
2. Go to the Tasks page (Admin -> Tasks)
3. Click on the "Hosts" icon in the top left menubar and wait until the list
   of unaccepted hosts is shown here.
4. Select 1st host and click on the "Accept" button.
5. Wait on this page and observe notifications and tasks which will be shown
   there later on.

Actual results

First of all, "Accept Node" task is shown in the task list and it's immediately
shown as "finished with success" (this is because this task is concerned with
updating RHSC 2.0 database and doesn't touch the machine in any way). Green
notification stating "Accept Node: node01.example.com is completed
successfully" and a green ok icon next to the Host item in the "Discovered
Hosts" list quickly follows.

Then another task is shown in the task list: "Initialize Node". This task
takes more time as it actually communicates with the machine.

As we already discussed in the Description section, this is because the process
of accepting a node consists of 2 tasks. And the problem is that a user is not
aware of the 2nd task "Initialize Node".  From his/hers point of view, the
success has been reported after clicking on the "Accept" button and there is
nothing else happening.

If the user opens the Tasks page, he would see the "initialize Node" task,
but it would be not clear to him that this task is actually part of the accept

Expected results

The UI should not report success immediately when the 1st task finishes, but
it should wait for the 2nd task so that:

 * the green notification is shown based on the result of "Initialize Node"
 * the green ok icon next to the host is shown after the 2nd task completes
   with success

Note that this is expected design as documented in "USM 1.0 Design" document:

> When the initialization task completes for any host, an inline notification
> [1] will appear to inform the user that the host was successfully accepted.

Comment 2 Martin Bukatovic 2016-05-20 15:03:07 UTC
Moreover this BZ has also more dangerous consequences when the 2nd task fails
in some way or it's not even started (see BZ 1313770). In such case, user would
be fooled into thinking that everything is ok while in fact, something went

See for example when I combine reproducers from both this very BZ 1337965 and
BZ 1313770, I would end up with node which is unusable/unfixable from the UI
itself and UI would not tell me anything about this.

Comment 3 Nishanth Thomas 2016-06-09 09:46:40 UTC
This is not a bug if 1338001 is fixed

Comment 4 Nishanth Thomas 2016-07-13 20:11:41 UTC
Since https://bugzilla.redhat.com/show_bug.cgi?id=1338001 is MODIFIED, moving this bug as well to MODIFIED as per the agreement earlier

Comment 5 Martin Bukatovic 2016-07-15 16:08:13 UTC
(In reply to Nishanth Thomas from comment #3)
> This is not a bug if 1338001 is fixed

Since BZ 1338001 has been implemented, I'm closing this BZ as WONFIX since it's
no longer applicable[1]. This decision is based on previous agreement with PM and
dev team, as can be noted in comment 3.

[1] patch fixing BZ 1338001 removed code affected by BZ 1337965 completely

Comment 6 Martin Bukatovic 2016-07-15 16:09:32 UTC
Removing nonsense in blocking graph: there is now way for BZ 1340506 to block
this BZ.

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