Description:

Creating the HumioAction/my-action with .spec.name: myAction and the HumioAction/my-duplicate-action with .spec.name: myaction and .spec.viewName will succeed. Worse, deleting the duplicate action is impossible if any alerts depend on the original action, and will result in "Reconciler error" and "Finalizer method returned error".

Further, since .spec.name is immutable, I can't edit HumioAction/my-duplicate-action to have it point to a different action, and the operator does not respect kubectl hard commands to delete:

kubectl delete HumioAction/my-duplicate-action --force --grace-period=0 --cascade=orphan

which returns

Warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely.
humioaction.core.humio.com "my-duplicate-action" force deleted

and then hangs forever.

The only way I could find was deleting all HumioAlerts dependent on my action, then deleting my actions, and then recreating everything.

Proposed Solutions:
Any one of the below would be sufficient.

• The operator could refuse to create resources with duplicate names
• The Kubernetes object name could be used as the action name, which would obviate the need for a check as Kubernetes will not allow duplicate names
• The operator could honor --cascade=orphan and/or --grace-period=0 --force by deleting the custom resource and leaving the underlying object in the Humio cluster.

Priority:

Low, honestly - I eventually figured out a way around the issue (delete and recreate everything) and my cluster doesn't require 100% uptime. Now that I know this bug exists, I will be more careful. I'm mostly reporting so that others are aware.