Closed aadeshpa closed 2 years ago
@horis233 @gyliu513
Hi @aadeshpa
Could you try to check the output of camel-k-operator subscription?
ODLM adds annotations into the subscription for operators. And the operator will stay in the cluster if there are some other OperandRequest
request it.
We were able to get this working by making changes in our top-level operator as per this issue: https://github.ibm.com/katamari/dev-issue-tracking/issues/22207
However we are leaving the camel-k stuff in the operandconfig
and operandregistry
and when we tried removing it along with the operandrequest
then the ODLM did not deleted the subscription correctly. cc: Vijai
Thank you @aadeshpa for the information
as @horis233 said in the internal ticket, ODLM can't find relevant information about the camel-k operator when it is got removed from OperandConfig
and OperandRegistry
.
If we wanna remove camel-k stuff from OperandConfig
and OperandRegistry
along with OperandRequest
,
we could remove it in OperandRequest
first.
And after OperandRequest
is in running
status again(indicates the camel-k has been removed), then we could remove camel-k stuff from OperandConfig
and OperandRegistry
/kind bug
What steps did you take and what happened: [A clear and concise description of what the bug is.]
While testing camel-k removal path for WASP 3.3 from orchestrator side, we see that as per our top level operator changes it got removed from the operandrequest , operandregistry and operandconfig, however, we still see the subscription and pod hanging around which was not deleted by ODLM as per expectation.
It is removed from this list in
oc get operandrequests ibm-aiops-application-manager -o yaml
Camel-k pods and subs still seen in the namespace
What did you expect to happen:
Anything else you would like to add: [Miscellaneous information that will assist in solving the issue.]
Environment:
kubectl version
):/etc/os-release
):