Closed dmvolod closed 3 years ago
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.
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
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 :)
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