Bug 1397205

Summary:	[RFE] Add possibility to remove baremetal nodes completely from Director management (power on/off, node replacement or deletion)
Product:	Red Hat OpenStack	Reporter:	Andreas Karis <akaris>
Component:	openstack-tripleo	Assignee:	James Slagle <jslagle>
Status:	CLOSED DUPLICATE	QA Contact:	Arik Chernetsky <achernet>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	11.0 (Ocata)	CC:	aschultz, bfournie, mburns, mcornea, rhel-osp-director-maint
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-10-04 15:55:53 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:

Description Andreas Karis 2016-11-21 22:06:16 UTC

Description of problem:
We need a way to avoid a node from being deleted or replaced in OSP Director. Either from user mistakes (such as deploying with a too low number of computes nodes, thus forcing a scale down) or from possible bugs in Director.

The idea is that customers / support may want to put a node into a mode where it cannot *ever* be redeployed/deleted/powered on or off by Director. 

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


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 2 Andreas Karis 2016-11-21 22:06:52 UTC

See also: https://bugzilla.redhat.com/show_bug.cgi?id=1389515

Comment 3 Andreas Karis 2016-11-21 22:08:36 UTC

This should be considered a safety feature. Similar to pulling the plug on Director. In this scenario, an already deployed node may get software updates, etc., but it may never be replace/restarted by Director (or ironic, for that matter).

Comment 4 Bob Fournier 2017-07-21 13:43:38 UTC

Although this RFE does refer to baremetal nodes I think any enhancement that would be added would come from the DF DFG, not Hardware Provisioning.  This is really a overcloud deployment issue as described in the referenced paper, not a hardware provisioning issue.  As the discussion for this bug is similar to https://bugzilla.redhat.com/show_bug.cgi?id=1389515, which is owned by the DF DFG I think this one should be too.  In addition its likely that the reasoning behind this enhancement may be satisfied other current or future deployment features, in that case the DF DFG would be the best ones to make that call.

Although I'm leery of ping-ponging the assignment, I'm changing the DFG to DF for these reasons. Let me know if you don't agree. Thanks.

Comment 8 Bob Fournier 2017-07-21 15:12:39 UTC

OK, thanks Andreas and Alex.  Alex - I can move this back to HardProv as there is an Ironic related request to prevent re-provisioning these nodes, although its not clear how that would be accomplished.  Almost like putting the node into maintenance during the deployment so Ironic doesn't manage it.

Comment 9 Bob Fournier 2018-08-29 14:37:22 UTC

Leaving open for future prioritization.

Comment 10 Dmitry Tantsur 2018-10-04 15:55:53 UTC

I don't believe we should prevent an explicit power action, it should not be done automatically anyway. A newer RFE is now tracking deletion/rebuild protection in Ironic.

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