Bug 1212367

Summary:	Ensure proper nodes states after enroll and before deployment
Product:	[Community] RDO	Reporter:	Dmitry Tantsur <dtantsur>
Component:	rdo-manager-cli	Assignee:	Dougal Matthews <dmatthew>
Status:	CLOSED EOL	QA Contact:	Shai Revivo <srevivo>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	Kilo	CC:	dmatthew
Target Milestone:	---
Target Release:	Kilo
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-05-19 16:04:55 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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 1 Dmitry Tantsur 2015-04-16 09:38:57 UTC

Example of retry code: https://github.com/stackforge/ironic-discoverd/blob/master/ironic_discoverd/utils.py#L106-L121

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.