Bug 1302386 - When introspection fails, the failure should be made very visible in stdout
When introspection fails, the failure should be made very visible in stdout
Status: CLOSED WONTFIX
Product: Red Hat OpenStack
Classification: Red Hat
Component: rhosp-director (Show other bugs)
7.0 (Kilo)
x86_64 Linux
unspecified Severity medium
: y3
: 7.0 (Kilo)
Assigned To: Dmitry Tantsur
Dan Yasny
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-27 11:54 EST by Dan Yasny
Modified: 2016-02-12 10:39 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Known Issue
Doc Text:
Cause: when introspection fails for many nodes, the actual error message might get lost in the output. Consequence: a user might assume that introspection ended successfully, even if it did not. Workaround (if any): a user should carefully read the introspection command output to spot error messages about failed introspection. Result:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-02-12 10:39:01 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)

  None (edit)
Description Dan Yasny 2016-01-27 11:54:54 EST
Description of problem:
A deployment where introspection fails produces a subdued message in one line, which quickly scrolls on, and end in "Discovery completed."

This might be missed by the deployer and he will move on, to an overcloud setup which will fail.

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

openstack-tripleo-heat-templates-0.8.6-112.el7ost.noarch
openstack-tripleo-image-elements-0.9.6-10.el7ost.noarch
openstack-tripleo-common-0.0.1.dev6-5.git49b57eb.el7ost.noarch
openstack-tripleo-puppet-elements-0.0.1-5.el7ost.noarch
openstack-tripleo-0.0.7-0.1.1664e566.el7ost.noarch
instack-undercloud-2.1.2-37.el7ost.noarch
instack-0.0.7-2.el7ost.noarch

[stack@undercloud72 ~]$ rhos-release -v
1.0.25


How reproducible:
always

Steps to Reproduce:
1. run instrospection where one of the nodes will fail
2. watch stdout
3.

Actual results:

Setting available nodes to manageable...
Starting introspection of node: e06fc6e3-d90d-4a8d-8ef8-748f33edf975
...
Waiting for discovery to finish...
Discovery for UUID e06fc6e3-d90d-4a8d-8ef8-748f33edf975 finished successfully.
...
Setting manageable nodes to available...
Node e06fc6e3-d90d-4a8d-8ef8-748f33edf975 has been set to available.
...
Discovery completed.

If a fault shows up somewhere in the middle, and there are many nodes, the error can only be seen when checking the status or scrolling back over the stdout.

Expected results:
Either output the full ironic status after introspection, or if there had been any errors, throw them into stdout after "Discovery completed." for better user visibility


Additional info:
Comment 2 Dan Yasny 2016-01-27 11:57:05 EST
This might also be solved by stressing the need to verify the introspection results in the docs, though it will be a better UX if we alert on failures as well.
Comment 3 Angus Thomas 2016-01-28 06:41:28 EST
Hi Dmitry, Can we get any simple changes to the output in time for 7.3? 

Either way, an update to the docs would make sense,
Comment 4 Dmitry Tantsur 2016-02-02 08:21:55 EST
Hi, sorry for the late answer. It could be a simple change, but I'm not really fond of making any changes to OSPd7 except for critical fixes.
Comment 5 Jaromir Coufal 2016-02-03 06:21:17 EST
Dmitry, can you please doc_text this for 7.3 please?
Comment 6 Dmitry Tantsur 2016-02-03 06:24:49 EST
Done (no clues what to put in the "result" field)
Comment 7 Dan Yasny 2016-02-03 08:50:23 EST
Ifwe're going for a doc change, I'd say tell the user to run ironic node-list and verify node statuses are as expected post-introspection

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