dapr uninstall --kubernetes show errors even if it is succeeded

[youngbupark]

Expected Behavior

dapr uninstall --kubernetes shows the error

Actual Behavior

dapr uninstall --kubernetes must be succeeded

Steps to Reproduce the Problem

1. dapr install --kubernetes
2. make sure dapr is installed in kubernetes
3. dapr uninstall --kuberentes

[pruthvidhodda]

Summary:
The issue is we are deleting a Custom Resource Definition(CRD) first and then it's associated Custom Resource (CR). But when a CRD is deleted all it's associated CR's will be deleted as well. So when we try to delete the CR later kubectl throws an error saying it couldn't find the requested resource.

Details:
When we do dapr uninstall --kubernetes we are internally calling kubectl delete -f daprManifestYaml

In our daprManifestYaml along with other resources we are creating a custom resource definition named configurations.dapr.io and also it's associated custom resource of kind Configuration (name:default).

When we do kubectl delete -f daprManifestYaml with a -v=4 verbose flag we can see that kubectl successfully deletes the CRD configurations.dapr.io
but throws an error when deleting the resource default

C:\Users\prdhodda>kubectl delete -f https://daprreleases.blob.core.windows.net/manifest/dapr-operator.yaml -v=4
customresourcedefinition.apiextensions.k8s.io "components.dapr.io" deleted
customresourcedefinition.apiextensions.k8s.io "configurations.dapr.io" deleted  << CRD deleted
secret "dapr-trust-bundle" deleted
secret "dapr-sidecar-injector-cert" deleted
serviceaccount "dapr-operator" deleted
clusterrole.rbac.authorization.k8s.io "secret-reader" deleted
clusterrolebinding.rbac.authorization.k8s.io "dapr-operator" deleted
clusterrolebinding.rbac.authorization.k8s.io "dapr-secret-reader" deleted
service "dapr-api" deleted
service "dapr-placement" deleted
service "dapr-sentry" deleted
service "dapr-sidecar-injector" deleted
deployment.apps "dapr-operator" deleted
deployment.apps "dapr-placement" deleted
deployment.apps "dapr-sentry" deleted
deployment.apps "dapr-sidecar-injector" deleted
mutatingwebhookconfiguration.admissionregistration.k8s.io "dapr-sidecar-injector" deleted
I0305 14:29:42.178023   26836 helpers.go:203] server response object: [{
  "metadata": {},
  "status": "Failure",
  "message": "error when deleting \"https://daprreleases.blob.core.windows.net/manifest/dapr-operator.yaml\": the server could not find the requested resource (delete configurations.dapr.io default)",
  "reason": "NotFound",
  "details": {
    "name": "default",
    "group": "dapr.io",
    "kind": "configurations",
    "causes": [
      {
        "reason": "UnexpectedServerResponse",
        "message": "404 page not found"
      }
    ]
  },
  "code": 404
}]
F0305 14:29:42.180551   26836 helpers.go:114] Error from server (NotFound): error when deleting "https://daprreleases.blob.core.windows.net/manifest/dapr-operator.yaml": the server could not find the requested resource (delete configurations.dapr.io default)

Let's discuss possible solutions for this issue.

@youngbupark @yaron2 thoughts?

[pruthvidhodda]

This is the idea after discussing with @youngbupark: the custom resource will be removed from the manifest file so that the "resource not found" error won't occur. But this will affect dapr init as the resource won't be deployed either. To solve that, we can programmaticaly deploy the resource for now. But in long term we have to come up with a better solution if there's any like separating custom resources into separate manifest file and using it while we do dapr init.

Thoughts on this approach and what do you suggest @yaron2 ?

[youngbupark]

@yaron2 What I suggest here is to add setting option to helm charts e.g. includeDefaultConfiguration
So when we generate template, we will set this flag option to false (--set includeDefaultConfiguration=false) and then manifest will not include default config.

It will be true by default, so it will not impact helm user to create default config by default.

@pruthvidhodda

But in long term we have to come up with a better solution if there's any like separating custom resources into separate manifest file and using it while we do dapr init.

long term plan is to use helm pkg inside dapr cli not rely on manifest yaml

[yaron2]

Closed with #294