What were you trying to do that didn't work? What is the impact of this issue to you?

`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.

Please provide the package NVR for which the bug is seen:

pcs-0.9.152-10.el7.x86_64

How reproducible is this bug?:

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)

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

Actual results

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

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