Migration not required but executed and migration job fails

[szeort]

Bug Report

What happened:
Migration job started and failed with
Error: while waiting for ready Service Catalog CRDs: CRDs are not available
No more error details.

What you expected to happen:
That is our first time to deploy service catalog and we do not expect to execute a migration job at all. There is a check if the catalog deployment already exists, and if exists, then the migration is executed. That logic maybe is not well working, since the deployment exists of course, but it is the new deployment not the old one.
Is it possible to force-discard migration? I mean, i do not want to execute it at all. I just want to deploy the catalog.

How to reproduce it (as minimally and precisely as possible):
I just deployed the HELM chart

helm repo add svc-cat https://svc-catalog-charts.storage.googleapis.com
kubectl create namespace catalog
helm install catalog svc-cat/catalog --namespace catalog --version 0.3.0

Anything else we need to know?:

Environment:

• Kubernetes version (use kubectl version):
  Server Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.1", GitCommit:"206bcadf021e76c27513500ca24182692aabd17e", GitTreeState:"clean", BuildDate:"2020-09-09T11:18:22Z", GoVersion:"go1.15", Compiler:"gc", Platform:"linux/amd64"}

• service-catalog version: 0.3.0

• Cloud provider or hardware configuration:
  SAP Gardener on Canary

• Do you have api aggregation enabled?

  • Do you see the configmap in kube-system?
    hmm, i do not see any configmap related to aggregation api in kube-system
  • Does it have all the necessary fields?
    • kubectl get cm -n kube-system extension-apiserver-authentication -o yaml and look for requestheader-XXX fields

• Install tools:

  • Did you use helm? What were the helm arguments? Did you --set any extra values?
    Yes - HELM used,
    helm repo add svc-cat https://svc-catalog-charts.storage.googleapis.com
    kubectl create namespace catalog
    helm install catalog svc-cat/catalog --namespace catalog --version 0.3.0

• Are you trying to use ALPHA features? Did you enable them?
  No

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community.
/close

[Kubernetes Prow Robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[Guillaume Berche]

@szeort I just experienced this same problem using helm upgrade instead of helm install which seems consistent with the fact that the migration tool is configured to run as a post-upgrade helm hook

https://github.com/kubernetes-sigs/service-catalog/blob/880e4007005c6848c6720150f5269499071cfbad/charts/catalog/templates/migration-job.yaml#L91-L101

Do you remember if you indeed run helm install and not helm upgrade when you reproduced the issue ?