RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1553782 - don't allow deletion of unmanaged resource
Summary: don't allow deletion of unmanaged resource
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: pcs
Version: 8.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Tomas Jelinek
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
Depends On: 1420298
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-03-09 14:27 UTC by Josef Zimek
Modified: 2023-08-16 22:02 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-08-20 07:27:18 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 3554531 0 None None None 2018-08-07 13:29:58 UTC

Description Josef Zimek 2018-03-09 14:27:44 UTC
Description of problem:

`pcs resource unmanage` is intended to get cluster's hands off the resource in order to perform i.e. maintenance (only monitoring is still enabled but failure is not considered critical while unamanged). If resource is deleted while in unmanaged state it ends up in ORPHANED state - it is removed from cib but still present in running configuration. This can cause various issues i.e. when unmanaged resource is stopped manually outside of cluster there might be problems with stopping the resource upon deletion (while unmanaged) which may end up with stonith being initiated - this is not desired with unmanaged resource.

Upon deletion of resource we should check if it is unmanaged. If yes, deletion should fail with warning that resource must be managed in order to delete. This will prevent subsequent problems. 

(Subsequent problems depend on type of resource. Some are less sensitive to this some more i.e. Oracle resource - when Oracle DB is stopped outside cluster while resource is unmanaged and then resource is deleted monitoring/stop fails and it is considered critical and leads to fencing).

Part of resource deletion is stop operation which may eventually fail (based on manual intervention on resource outside cluster). If user wants to delete resource it should be done while resource is managed so stop/monitoring operation can proceed gracefully. 


Version-Release number of selected component (if applicable):
pcs-0.9.152-10.el7.x86_64 
pacemaker-1.1.15-11.el7_3.2.x86_64



How reproducible:
depends on manual actions performed on resource while unmanaged - i.e. stopping outside cluster and then deleting resource via pcs. i.e. IPaddr2 resource just ends up in ORPHANED state but oracle resource fails to stop/monitor

Steps to Reproduce:
1. stop oracle db manuall outside cluster while oracle resource is unmanaged (make sure PID doesn't exist)
2. delete the oracle resource
3. node gets fenced upon stop/monitoring failure - (but monitoring should not be critical while unmanaged)

Actual results:
unmanaged resource gets deleted and resource ends up ORPHANED which may lead to various problems

Expected results:
check for unmanage flag when deleting resource. resource deletion is not allowed in unmanaged state - print warning to manage the resource prior deletion

Additional info:
logically there is no need to unmanage resource in order to delete it because it can be deleted while managed (either running, stopped, failed). while resource is unmanaged we still expect cluster to keep monitoring the resource unless manually disabled. yet we allow to delete it in such a state which is bit contradicting - at same time  allow to delete it from cib but we keep it in running config

Comment 10 RHEL Program Management 2021-08-20 07:27:18 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

Comment 11 bugzilla 2023-08-16 22:02:24 UTC
In case anyone else hits this, here is the work-around:

`pcs resource refresh <resource_name>`


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