Bug 1311628 - Introspection on a node already introspected does not update the ironic node extra field
Introspection on a node already introspected does not update the ironic node ...
Status: CLOSED DUPLICATE of bug 1311629
Product: Red Hat OpenStack
Classification: Red Hat
Component: rhosp-director (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: 8.0 (Liberty)
Assigned To: Angus Thomas
Arik Chernetsky
Depends On:
  Show dependency treegraph
Reported: 2016-02-24 10:52 EST by Sid Ahmed Sadouni
Modified: 2016-02-24 10:56 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-02-24 10:56:25 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Sid Ahmed Sadouni 2016-02-24 10:52:52 EST
Description of problem:

I did the introspection on my nodes and did a successful deployment.
Then I needed to modify the number of logical drive on my ceph node (from 7 to 6 logical drive).
Before redeploying, I wanted to run the introspection manually on the 6 nodes concerned by this modification.
The ironic node-show command show a non up to date extra field with still 7 disk.
But when we look at the swift object associated to this node, we can see that this one is up to date.
So we have a difference between what is displayed by ironic command and what is stored in the swift object.

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

I am deploying with OSPD 7.2

How reproducible:

Was reproducible for all my 6 ceph nodes.

Steps to Reproduce:
1. Do instrospection
2. Modify the hardware disk configuration (moved from 7 to 6 logical drives)
3. Run introspection manually
4. Notice with ironic node-show command that the extra field is not updated.

Find the step by step info here : http://pastebin.test.redhat.com/351450

Actual results:

The information displayed in the extra field is not updated with the new introspected information.
The swift object linked to the node is correctly updated

Expected results:
the extra field should display the correct information about the node.

Additional info:
You can find a step by step demonstration of the bug here : http://pastebin.test.redhat.com/351450

We can have a correct value if we set the extra field value to empty with the following command :
ironic node-update ac2cad36-2ffd-4509-b51c-51c89fd09e74 replace extra='{}'

result :
| Property               | Value                                                                 |
| target_power_state     | None                                                                  |
| extra                  | {}                                                                    |

Now, if we re run an introspection it will update correctly this field :
openstack baremetal introspection start ac2cad36-2ffd-4509-b51c-51c89fd09e74
ironic node-show ac2cad36-2ffd-4509-b51c-51c89fd09e74
| Property               | Value                                                                 |
| target_power_state     | None                                                                  |
| extra                  | {u'on_discovery': u'true'}   

then :
extra                  | {u'newly_discovered': u'true', u'block_devices': {u'serials':         |
|                        | [u'600508b1001cddbff263e9d8d23d4233',                                 |
|                        | u'600508b1001c6f0f063af2ebd7818ce6',                                  |
|                        | u'600508b1001cd44cdd1630a8130fc3a2',                                  |
|                        | u'600508b1001c454ea69b9809d710fff2',                                  |
|                        | u'600508b1001ccd0c3314b4e840772cda',                                  |
|                        | u'600508b1001cc834a30f7c1717af1604']}, u'hardware_swift_object': u    |
|                        | 'extra_hardware-ac2cad36-2ffd-4509-b51c-51c89fd09e74'}
Comment 2 Mike Burns 2016-02-24 10:56:25 EST

*** This bug has been marked as a duplicate of bug 1311629 ***

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