08961919b5
- Previously the golang code would create a Service and an APIService. The APIService would be given an owner reference which pointed to the namespace in which the app was installed. - This prevented the app from being uninstalled. The namespace would refuse to delete, so `kapp delete` or `kubectl delete` would fail. - The new approach is to statically define the Service and an APIService in the deployment.yaml, except for the caBundle of the APIService. Then the golang code will perform an update to add the caBundle at runtime. - When the user uses `kapp deploy` or `kubectl apply` either tool will notice that the caBundle is not declared in the yaml and will therefore avoid editing that field. - When the user uses `kapp delete` or `kubectl delete` either tool will destroy the objects because they are statically declared with names in the yaml, just like all of the other objects. There are no ownerReferences used, so nothing should prevent the namespace from being deleted. - This approach also allows us to have less golang code to maintain. - In the future, if our golang controllers want to dynamically add an Ingress or other objects, they can still do that. An Ingress would point to our statically defined Service as its backend. Signed-off-by: Andrew Keesler <akeesler@vmware.com> |
||
|---|---|---|
| .. | ||
| apiserver | ||
| autoregistration | ||
| certauthority | ||
| constable | ||
| controller/logindiscovery | ||
| downward | ||
| mocks/mockcertissuer | ||
| registry/loginrequest | ||
| server | ||