operand-deployment-lifecycle-manager
operand-deployment-lifecycle-manager copied to clipboard
IBM
ODLM reports error when removing opreq due to opreg/opcon missing
/kind bug
What steps did you take and what happened:
Just simply created one opreg, one opcon, and one opreq to launch some workload. Then delete opreg and opcon first, now try to delete opreq, ODLM will report some errors such as below:
E0718 02:10:18.926938 1 reconcile_operator.go:65] Failed to get suitable OperandRegistry default/foo: operandregistries.operator.ibm.com "foo" not found
E0718 02:10:18.938672 1 operandrequest_controller.go:139] failed to reconcile Operators for OperandRequest default/foo: operandregistries.operator.ibm.com "foo" not found
What did you expect to happen:
Although it might not be a common case to delete the opreg and opcon intentionally before delete opreq, for a clean uninstall scenario in a system, it might be a problem, where it's not someone who does it manually, but automation code drives it.
By looking at the code, it seems ODLM needs some info from opreg and opcon before it can delete the subs and csv associated w/ the opreq to be deleted.
Wonder if there is possible to remediate this by enforcing the deletion of these subs and csv w/o opreg/opcon, or block the deletion of opreg/opcon by approaches such as using finalizer, given the fact that opreq requires opreg/opcon to be there intentionally.
Environment:
- ODLM version: latest
- Minikube/KIND/OCP version: kind v0.12.0-alpha+718ede73045ce3
- Kubernetes version: (use
kubectl version): v1.21.2 - OS (e.g. from
/etc/os-release): RHEL
@Daniel-Fan @horis233 Any comment on that? Is this a desired behavior, or something could be addressed?
Hi @morningspace It is desired behaviour. As for the enhancement, we can refactor the status of the operandrequest to include more operator and cs information, then we can decouple the operandrequest with OperandRegistry and OperandConfig.
Thanks @horis233. To decouple the OperandRequest w/ OperandRegistry and OperandConfig, that makes sense to me. Before that, I guess I would keep OperandRegistry and OperandConfig there when I delete OperandRequest. This will address the issue that I am having for now.