You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
/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:
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:
kubectl version
): v1.21.2/etc/os-release
): RHELThe text was updated successfully, but these errors were encountered: