uninstall: remove kuadrant control plane deployment from the cluster

[dmvolod]

This PR related to the removing whole kuadrant control plane deployment from the cluster Still thinking about to remove CRD's from cluster or keep them as right now implementing @eguzki could please review when possible

[eguzki]

Good job :medal_military:

This issue partially implements #6. Another meaningful capability of this command would disabling Kuadrant protection to some specific API (or domain name).

I have tested and working like a charm :+1:

I would not delete the namespace and CRDs. Deleting the namespace, the uninstall command would be much simpler, but the namespace could contain some customer resources that would also be deleted. Regarding the CRD's, being cluster wide, they could be used somewhere else.

[dmvolod]

Thanks for review, @eguzki

Another meaningful capability of this command would disabling Kuadrant protection to some specific API (or domain name).

However uninstall a bit confusing for me for this kind command. Does it means that we need to set label discovery.kuadrant.io/enabled: to false for the service where annotation discovery.kuadrant.io/api-name is equals to API name or I'm wrong?

apiVersion: v1
kind: Service
metadata:
  name: cats-api
  annotations:
    discovery.kuadrant.io/scheme: "http"
    discovery.kuadrant.io/api-name: "cats"
    discovery.kuadrant.io/tag: "production"
    discovery.kuadrant.io/port: "80"
    discovery.kuadrant.io/oas-configmap: "cats-oas"
  labels:
    discovery.kuadrant.io/enabled: "true"
spec:
  selector:
    svc: cats
  ports:
    - port: 80
      protocol: TCP
      targetPort: 3000

[eguzki]

You are right. However, that is only one easy and convenient way to protect your API. But the customer could also decide to not annotate a service and create (manually or via some UI) an API apis.networking.kuadrant.io resource directly. In that particular case, the uninstall command would have to delete the API resource.

Actually, for kuadrant, the API.networking.kuadrant.io is the source of truth for the API definition. The protection is defined in the APIProduct custom resource. The kuadrant labels and annotation in the service is called service discovery, a convenient way to define the API and the kuadrant controller will, behind the scene, create an API custom resource for you.

This design is still under development and naming and relations may change in the future. Feel free to propose here :)