Bug 1185823 - When registering bare metals they stay in "discovering" status forever
Summary: When registering bare metals they stay in "discovering" status forever
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo
Version: Director
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ga
: Director
Assignee: James Slagle
QA Contact: Udi
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-01-26 11:29 UTC by Udi
Modified: 2015-08-05 13:50 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-08-05 13:50:09 UTC
Target Upstream Version:


Attachments (Terms of Use)
Packet capture from discovery registration on bare metal (2.92 KB, application/octet-stream)
2015-02-13 20:45 UTC, Dan Sneddon
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2015:1549 normal SHIPPED_LIVE Red Hat Enterprise Linux OpenStack Platform director Release 2015-08-05 17:49:10 UTC

Description Udi 2015-01-26 11:29:05 UTC
Description of problem:
When registering a new node by using the IPMI driver, giving the management IP/user/password, and choosing "discover missing attributes" - the node is stuck in "discovering" status forever


Version-Release number of selected component (if applicable):
openstack-tripleo-0.0.5-2c3fb309727671130a32b4c19de48ec22c8530aa1.el7ost.noarch
openstack-tripleo-heat-templates-0.7.9-10.el7ost.noarch
openstack-tripleo-image-elements-0.8.10-19.el7ost.noarch
python-tuskarclient-0.1.15-3.el7ost.noarch
openstack-tuskar-0.4.15-4.el7ost.noarch
openstack-tuskar-ui-0.2.0-10.el7ost.noarch
openstack-tuskar-ui-extras-0.0.2-2.el7ost.noarch
openstack-ironic-api-2014.2-3.el7ost.noarch
openstack-ironic-conductor-2014.2-3.el7ost.noarch
openstack-ironic-common-2014.2-3.el7ost.noarch
openstack-ironic-discoverd-0.2.5-1.el7ost.noarch
python-ironicclient-0.3.1-1.el7ost.noarch


How reproducible:
100%


Steps to Reproduce:
1. From the "Nodes" screen click on "Register Nodes"
2. Provide the details of a real machine 
3. Choose the "Discover missing attributes" option 
4. Click the Register button


Actual results:
The power state of the machine is discovered correctly, and you can even turn the machine off - but the discovery process never ends.

Comment 2 James Slagle 2015-01-28 21:21:57 UTC
we haven't done significant baremetal testing for the TripleO Tech Preview. I'm not sure if baremetal + discovery has been tried before given time and resource constraints. Just lowering the priority on this one to indicate that baremetal is not high priority right now.

Comment 4 Dan Sneddon 2015-02-13 20:42:51 UTC
I am running into this bug on bare metal, and I decided to do a little bit of troubleshooting. I ran a tcpdump on the undercloud host and I see:

Server<-client
<- ARP request
-> ARP response
<- ICMP Echo Request
-> ICMP Echo Reply
<- TCP SYN port 5050
-> TCP SYN/ACK
<- TCP ACK
<- HTTP port 5050 POST /v1/continue HTTP/1.1
-> HTTP 202 accepted

Of course, even though the discoveryd HTTP server is accepting the JSON sent from the discovery client, the state never changes.

Comment 5 Dan Sneddon 2015-02-13 20:45:38 UTC
Created attachment 991594 [details]
Packet capture from discovery registration on bare metal

This is a packet capture from the undercloud host that shows the discovery image connecting and registering with the discoveryd daemon. The HTTP response is 202 accepted, but the host never gets properly registered.

Comment 8 errata-xmlrpc 2015-08-05 13:50:09 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-2015:1549


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