RDO tickets are now tracked in Jira https://issues.redhat.com/projects/RDO/issues/
Bug 1212367 - Ensure proper nodes states after enroll and before deployment
Summary: Ensure proper nodes states after enroll and before deployment
Keywords:
Status: CLOSED EOL
Alias: None
Product: RDO
Classification: Community
Component: rdo-manager-cli
Version: Kilo
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: Kilo
Assignee: Dougal Matthews
QA Contact: Shai Revivo
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-04-16 09:33 UTC by Dmitry Tantsur
Modified: 2016-05-19 16:04 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-05-19 16:04:55 UTC
Embargoed:


Attachments (Terms of Use)

Description Dmitry Tantsur 2015-04-16 09:33:27 UTC
In Kilo release Ironic has few more states that nodes can take. State changes are done via node.set_provision_state command.

0. Currently nodes are enrolled in AVAILABLE state, which is the same as Juno "NOSTATE" or "None" and is meant for deployment
1. After enrolling nodes should be advanced to MANAGEABLE state for discovery and ready state work (set_provision_state(uuid, 'manage')).
2. Before deployment nodes should be moved back to AVAILABLE: set_provision_state(uuid, 'provide')

A few notes:
1. While very fast now, these actions are still async. It's better to wait for actual state to be reflected in node.show. When cleaning is introduced, 'provide' action can take much more time. And in the future 'manage' action will validate node manageability (thus state name).
2. Until retry is implemented in ironicclient, you should be ready to retry in case of error 409 on this call. See https://bugzilla.redhat.com/show_bug.cgi?id=1212134 for details.

Comment 2 Dmitry Tantsur 2015-04-17 15:28:35 UTC
Re retry: do not bother, ironicclient will have it very soon.

Comment 4 Dougal Matthews 2015-06-16 07:32:05 UTC
This was implemented as part of the recent deploy work which means the CLI now sets the state and waits for the results (by polling).

Comment 5 Mike McCune 2016-03-28 22:30:10 UTC
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

Comment 7 Chandan Kumar 2016-05-19 16:04:55 UTC
This bug is against a Version which has reached End of Life.
If it's still present in supported release (http://releases.openstack.org), please update Version and reopen.


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