removing an operator without removing k8s CRDs

Hi
Does anyone know if there is a way to properly remove an operator from a namespace, without having an affect on the AWX specific CRDs?

My setup consist of two namespace with each their operator. so if i run “make undeploy” for one of the namespaces, the other awx installation in the other namespace is affected, since the crd “awx” is gonna be removed.

I am running make from the same directory on the tag “0.19.0”

Dear regards
Magnus

Hi Magnus,

I don’t have the full answer to your question but in my case (AWX 19.4.0 w/ operator 0.14.0 over K3S) the CRD is namespace-scoped:
$ kubectl describe awx
Name: awx
Namespace: awx-vincent
Labels: app.kubernetes.io/component=awx
app.kubernetes.io/managed-by=awx-operator
app.kubernetes.io/name=awx
app.kubernetes.io/operator-version=
app.kubernetes.io/part-of=awx
Annotations:
API Version: awx.ansible.com/v1beta1

It is thus strange to me that the undeploy step from one namespace affects the other CRD (I expect it removes the CRD from its associated namespace but not the other namespaces).

I would expect that you need to set the NAMESPACE variable when doing the undeploy step for instance.

Would you mind sharing more info on the commands you use to undeploy as well as your namespaces and CRDs in your cluster?

HTH,

Vincent

Hey Vincent
My setup consist of two operators in each their namespace running on a single node k3s cluster.
yes the “awx” is defined in each of the namespaces, the problem is that still when i execute “make undeploy” with a namespace defined as an env var, resources in the other namespace are affected…

this is my strategy for removing a cluster:

kubectl delete awx awx-<name> -n awx-<namespace>
cd awx-operator/
export NAMESPACE=awx-<namespace>
make undeploy

maybe i just test around with different operator versions, to see if there is any difference…

Best regards
Magnus

Magnus,

Thanks for the additional information. It might be a bug in the cleanup step.

Could it also be that the undeploy step deletes the CRD too (and that you do not need to do it yourself)? Or that it picks up the first CRD with the correct name, regardless of the namespace?

I also don’t know if, in addition to being in separate namespace names, the actual CRDs and resources also need to have a different name too.

Let us know how it goes,

Vincent

Not sure if this is the right or best way… but if I run kubectl get deployments -A -l control-plane=controller-manager I get the awx-operator-controller-manager deployment listed in both namespaces I have AWX operator deployed. While there are some extra configurations that would be left behind if you’re looking to simply remove the controller and leave the CRDS you could remove the deployment in the namespace you want to remove and thus leave the other. If you’ve already deleted the AWX deployments themselves this should be the only AWX-related pod running in that namespace. Then you could clean up the ConfigMaps and Secrets, I think I recall 1 Secret and 2 ConfigMaps that are awx-operator prefixed. You may also find you still have a few laying around from the AWX deployments themselves as well.

Hello all,

As mentioned above, you can delete the deployment object for the awx-operator’s manager, which will remove the operator and leave behind all AWX CR’s.

kubectl delete deployment awx-operator-controller-manager --namespace

This will however leave behind a couple other artifacts that you may wish to clean up:

    • serviceaccount/awx-operator-controller-manager
    • service/awx-operator-controller-manager-metrics-service
    • configmap/awx-operator
    • configmap/awx-operator-awx-manager-config
    • 3 secrets with prefix awx-operator-controller-manager

The reason why the make undeploy target also deletes your AWX CR’s is because the API’s/Custom Resource Definitions themselves get cleaned up by the undeploy target.

Thanks,
Christian

Hi Christian
Thanks for the respond, this answers my question!
thank you all for the participation in fixing my problem.

Best wishes,
Magnus