Bug 1271250 - When introspection fails Ironic must mark Discovery as Failed
Summary: When introspection fails Ironic must mark Discovery as Failed
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-rdomanager-oscplugin
Version: 7.0 (Kilo)
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 8.0 (Liberty)
Assignee: Brad P. Crochet
QA Contact: Raviv Bar-Tal
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-10-13 13:30 UTC by Ofer Blaut
Modified: 2016-04-07 21:41 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
In previous releases, a bug made it possible for failed nodes to be marked as available. Whenever this occurred, deployments failed because nodes were not in a proper state. This update backports an upstream patch to fix the bug.
Clone Of:
Environment:
Last Closed: 2016-04-07 21:41:40 UTC
Target Upstream Version:


Attachments (Terms of Use)
output (3.98 KB, text/plain)
2015-10-13 13:30 UTC, Ofer Blaut
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2016:0604 0 normal SHIPPED_LIVE Red Hat OpenStack Platform 8 director Enhancement Advisory 2016-04-08 01:03:56 UTC

Description Ofer Blaut 2015-10-13 13:30:27 UTC
Created attachment 1082427 [details]
output

Description of problem:

openstack baremetal introspection bulk start finish with Discovery completed , while it failed ( i thought ERROR: rdomanager_oscplug... was solved )


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


How reproducible:


Steps to Reproduce:
1.Deploy virt setup  with 
export TESTENV_ARGS="--baremetal-bridge-names 'brbm brbm1 brbm2'" ( to hit fail introspection - https://bugzilla.redhat.com/show_bug.cgi?id=1234601 )
2. check Last line of the output 
3.

Actual results:


Expected results:


Additional info:

Comment 1 Mike Burns 2015-10-15 16:11:48 UTC
Ofer,  I'm confused, the summary and description seem to be saying the opposite things.  

I think the description is right.  If introspection fails, the cli should report failure.  I'm updating the summary, but please confirm.

Comment 3 Ofer Blaut 2015-10-21 10:31:26 UTC
You are right :-)

Comment 4 Brad P. Crochet 2016-02-08 13:27:18 UTC
This should be fixed. Please confirm.

Comment 7 Dmitry Tantsur 2016-03-29 15:31:05 UTC
I've simulated an error by modifying the ironic-inspector source to raise an exception. Results show the expected error message and stay "manageable":

[stack@instack ~]$ openstack baremetal introspection bulk start
Setting nodes for introspection to manageable...
Starting introspection of node: 792c0e83-26ec-4ad4-a775-b1021ea2fdda
Starting introspection of node: 9f471f94-7535-44f0-a1ef-1b75a1ebbd3a
Waiting for introspection to finish...
Introspection for UUID 792c0e83-26ec-4ad4-a775-b1021ea2fdda finished with error: Unexpected exception in background introspection thread
Introspection for UUID 9f471f94-7535-44f0-a1ef-1b75a1ebbd3a finished with error: Unexpected exception in background introspection thread
Setting manageable nodes to available...
Introspection completed with errors:
792c0e83-26ec-4ad4-a775-b1021ea2fdda: Unexpected exception in background introspection thread
9f471f94-7535-44f0-a1ef-1b75a1ebbd3a: Unexpected exception in background introspection thread
[stack@instack ~]$ echo $?
1
[stack@instack ~]$ ironic node-list
+--------------------------------------+--------+--------------------------------------+-------------+--------------------+-------------+
| UUID                                 | Name   | Instance UUID                        | Power State | Provisioning State | Maintenance |
+--------------------------------------+--------+--------------------------------------+-------------+--------------------+-------------+
| 792c0e83-26ec-4ad4-a775-b1021ea2fdda | node-2 | None                                 | power off   | manageable         | False       |
| 9f471f94-7535-44f0-a1ef-1b75a1ebbd3a | node-3 | None                                 | power off   | manageable         | False       |
+--------------------------------------+--------+--------------------------------------+-------------+--------------------+-------------+

Comment 9 errata-xmlrpc 2016-04-07 21:41:40 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://rhn.redhat.com/errata/RHEA-2016-0604.html


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