We have seen the following situation happen.
There are two kinds created in a cluster - say KindA, KindB.
We create application instance for KindA, name it - appA
We delete the namespace corresponding to the appA instance using kubectl delete ns appA, without deleting the app instance itself.
We then create application instance for KindB and name it - appA.
KubePlus now creates the Namespace appA again.
Then, we realize that we have a dangling appA instance. So we kubectl delete KindA appA.
This causes the new appA namespace, which now corresponds to the appA instance for KindB, to get deleted. The helm release for appA instance for KindB also gets deleted.
This is a bug as the new appA namespace does not belong to KindA. So when we delete KindA appA, it should just delete the
appA object, without deleting the release or the namespace.
We have seen the following situation happen.
There are two kinds created in a cluster - say KindA, KindB.
We create application instance for KindA, name it - appA
We delete the namespace corresponding to the appA instance using
kubectl delete ns appA, without deleting the app instance itself.We then create application instance for KindB and name it - appA.
KubePlus now creates the Namespace appA again.
Then, we realize that we have a dangling appA instance. So we
kubectl delete KindA appA.This causes the new appA namespace, which now corresponds to the appA instance for KindB, to get deleted. The helm release for appA instance for KindB also gets deleted.
This is a bug as the new appA namespace does not belong to KindA. So when we delete KindA appA, it should just delete the
appA object, without deleting the release or the namespace.