ping @ncdc @vincepri

<!-- please add a icon to the title of this PR (see VERSIONING.md), and delete this line and similar ones --> <!-- the icon will be either ⚠ (:warning:, major), ✨ (:sparkles, minor), 🐛 (:bug:, patch), 📖 (:book:, docs), or 🌱 (:seedling:, other) -->

<!-- What does this do, and why do we need it? -->

This is a very minimal implementation of #723

With this in place, one can define a readiness check for webhook like this:

err = mgr.AddReadyzCheck("ready", func(_ *http.Request) error {
		if mgr.GetWebhookServer().Started {
			return nil
		}
		return errors.New("Webhook server not yet started")
	})

there's still a possibility for a very small race because technically all the paths for webhook are bound when srv.Serve is done. But the possibility of hitting it is very small considering that the readiness check has to pick it up, return ready and someone has to make a request over network to that webhook - that will be definitely slower than the processing inside srv.Serve.

If anyone has better idea, I am all ears.

I'll investigate the failures tomorrow

Signed-off-by: Alena Varkockova [email protected]

<!-- Thanks for sending a pull request! Here are some tips for you:

1. If this is your first time, please read our contributor guidelines: https://github.com/kudobuilder/kudo/blob/main/CONTRIBUTING.md
2. Make sure you have added and ran the tests before submitting your PR
3. If the PR is unfinished, start it as a Draft PR: https://github.blog/2019-02-14-introducing-draft-pull-requests/ -->

What this PR does / why we need it: Not only --wait, also the health module should read the ready property, not phase == running.

See https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/ for more context.

shouldn't we aim for something more user friendly then just serialized CRD status? 🤔

deleted

hmm why is this better than what was here before? 🤔

why are you passing in instance as well as field on that instance? 🤔 should we just pass in an instance?

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security sensitive, please disclose it privately to a security contact: https://github.com/kudobuilder/kudo/blob/main/SECURITY_CONTACTS -->

What happened: Currently, when uninstalling stuff as a first step of upgrade, we use foreground delete propagation https://github.com/kudobuilder/kudo/blob/5c68af2007d6e165d3a9627f12aa9584dc16782c/pkg/kudoctl/kudoinit/manager/manager.go#L73 and we falsely assumed that's blocking until it gets deleted which is not true. API server returns response when object is marked to be deleted but then it could take a substantial amount of time until object gets deleted (depending on the finalizers).

When deleting something as part of upgrade, we should always "block" and wait until really deleted (probably with some timeout) and not proceed with upgrade until that's done.

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

Environment:

• Kubernetes version (use kubectl version):
• Kudo version (use kubectl kudo version):
• Operator:
• operatorVersion:
• Cloud provider or hardware configuration:
• OS (e.g. from /etc/os-release):
• Kernel (e.g. uname -a):
• Install tools:
• Others:

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security sensitive, please disclose it privately to a security contact: https://github.com/kudobuilder/kudo/blob/main/SECURITY_CONTACTS -->

What happened:

./bin/kubectl-kudo init --upgrade --version 0.15.0
$KUDO_HOME has been configured at /Users/alenavarkockova/.kudo
Verify that 0 required migrations can be applied
Upgrade KUDO
Run 0 migrations
✅ installed crds
✅ installed namespace
✅ installed service account
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x189198c]

goroutine 1 [running]:
k8s.io/apimachinery/pkg/apis/meta/v1/unstructured.(*Unstructured).GetAPIVersion(...)
	/Users/alenavarkockova/go/pkg/mod/k8s.io/[email protected]/pkg/apis/meta/v1/unstructured/unstructured.go:218
k8s.io/apimachinery/pkg/apis/meta/v1/unstructured.(*Unstructured).GroupVersionKind(0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
	/Users/alenavarkockova/go/pkg/mod/k8s.io/[email protected]/pkg/apis/meta/v1/unstructured/unstructured.go:426 +0x6c
github.com/kudobuilder/kudo/pkg/kudoctl/kudoinit/prereq.installUnstructured(0x2925220, 0xc0006a2960, 0x0, 0xc000000180, 0x200000003)
	/Users/alenavarkockova/go/src/github.com/kudobuilder/kudo/pkg/kudoctl/kudoinit/prereq/webhook.go:340 +0x43
github.com/kudobuilder/kudo/pkg/kudoctl/kudoinit/prereq.(*KudoWebHook).installWithCertManager(0xc000648140, 0xc00036ab10, 0x1, 0x1)
	/Users/alenavarkockova/go/src/github.com/kudobuilder/kudo/pkg/kudoctl/kudoinit/prereq/webhook.go:125 +0x64
github.com/kudobuilder/kudo/pkg/kudoctl/kudoinit/prereq.(*KudoWebHook).Install(0xc000648140, 0xc00036ab10, 0xc0009cfa80, 0x1)
	/Users/alenavarkockova/go/src/github.com/kudobuilder/kudo/pkg/kudoctl/kudoinit/prereq/webhook.go:158 +0x6c
github.com/kudobuilder/kudo/pkg/kudoctl/kudoinit/setup.(*Installer).Install(0xc0006e1080, 0xc00036ab10, 0xc0009cfb40, 0x1)
	/Users/alenavarkockova/go/src/github.com/kudobuilder/kudo/pkg/kudoctl/kudoinit/setup/setup.go:143 +0x92
github.com/kudobuilder/kudo/pkg/kudoctl/kudoinit/setup.(*Installer).Upgrade(0xc0006e1080, 0xc00036ab10, 0x0, 0x0)
	/Users/alenavarkockova/go/src/github.com/kudobuilder/kudo/pkg/kudoctl/kudoinit/setup/setup.go:118 +0x292
github.com/kudobuilder/kudo/pkg/kudoctl/cmd.(*initCmd).runUpgrade(0xc00034c0d0, 0xc0006e1080, 0xc00036ab10, 0x0)
	/Users/alenavarkockova/go/src/github.com/kudobuilder/kudo/pkg/kudoctl/cmd/init.go:262 +0xcb
github.com/kudobuilder/kudo/pkg/kudoctl/cmd.(*initCmd).run(0xc00034c0d0, 0x26989dc, 0x9)
	/Users/alenavarkockova/go/src/github.com/kudobuilder/kudo/pkg/kudoctl/cmd/init.go:207 +0x1e3
github.com/kudobuilder/kudo/pkg/kudoctl/cmd.newInitCmd.func1(0xc0000fcb00, 0xc00036b980, 0x0, 0x3, 0x0, 0x0)
	/Users/alenavarkockova/go/src/github.com/kudobuilder/kudo/pkg/kudoctl/cmd/init.go:104 +0x128
github.com/spf13/cobra.(*Command).execute(0xc0000fcb00, 0xc00036b950, 0x3, 0x3, 0xc0000fcb00, 0xc00036b950)
	/Users/alenavarkockova/go/pkg/mod/github.com/spf13/[email protected]/command.go:842 +0x453
github.com/spf13/cobra.(*Command).ExecuteC(0xc0000fc580, 0x0, 0x0, 0xc0000ae058)
	/Users/alenavarkockova/go/pkg/mod/github.com/spf13/[email protected]/command.go:950 +0x349
github.com/spf13/cobra.(*Command).Execute(...)
	/Users/alenavarkockova/go/pkg/mod/github.com/spf13/[email protected]/command.go:887
main.main()
	/Users/alenavarkockova/go/src/github.com/kudobuilder/kudo/cmd/kubectl-kudo/main.go:24 +0x27

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

Environment:

• Kubernetes version (use kubectl version):
• Kudo version (use kubectl kudo version):
• Operator:
• operatorVersion:
• Cloud provider or hardware configuration:
• OS (e.g. from /etc/os-release):
• Kernel (e.g. uname -a):
• Install tools:
• Others:

I think the container ready and webhook ready is captured in "pod phases" so it's already exposed by kubernetes. I don't see much value in duplicating those into events as one already has this information on every kubernetes cluster.

I would personally be inclined to close this.

Previous to https://github.com/kudobuilder/kudo/pull/1629 there was a check to verify image name when looking for kudo readiness. As well commented on the PR: https://github.com/kudobuilder/kudo/pull/1629#discussion_r465482145 We need to make sure that upgrades are managed correctly. Part of that is making sure we are looking at the status on the right object.

As pointed out as a response to the comment, we likely need to either:

1. wait for deletes to complete before install or
2. capture any statefulset prior to init and work with revision changes to ensure that we are capturing the progress on the correct statefulset.

we did but I removed it again so we're 1.15 :)

What happened:

Our tests run kudo init --wait and `kudo install in quick succession, which fails due to webhook not being ready.

      kuttl: logger.go:42: 13:10:24 |  | running command: [kubectl kudo init --wait]
      kuttl: logger.go:42: 13:10:24 |  | $KUDO_HOME has been configured at /root/.kudo
      kuttl: logger.go:42: 13:10:24 |  | ✅ installed crds
      kuttl: logger.go:42: 13:10:24 |  | ✅ installed namespace
      kuttl: logger.go:42: 13:10:24 |  | ✅ installed service account
      kuttl: logger.go:42: 13:10:24 |  | ✅ installed webhook
      kuttl: logger.go:42: 13:10:24 |  | ✅ installed kudo controller
      kuttl: logger.go:42: 13:10:24 |  | ⌛Waiting for KUDO controller to be ready in your cluster...
      kuttl: logger.go:42: 13:10:31 |  | running command: [kubectl kudo install /.../blah --instance blah-instance --namespace blah ... --wait --wait-time 750]
      kuttl: logger.go:42: 13:10:31 |  | operator blah/blah created
      kuttl: logger.go:42: 13:10:31 |  | operatorversion blah/blah-0.3.1 created
      kuttl: logger.go:42: 13:10:31 |  | Error: failed to install instance blah/blah-instance: installing Instance: Internal error occurred: failed calling webhook "instance-admission.kudo.dev": Post https://kudo-controller-manager-service.kudo-system.svc:443/admit-kudo-dev-v1beta1-instance?timeout=30s: dial tcp 10.0.11.58:443: connect: connection refused

What you expected to happen:

The former command should only return once KUDO is fully ready for action.

How to reproduce it (as minimally and precisely as possible):

See above.

Anything else we need to know?:

https://kubernetes.slack.com/archives/CG3HTFCMV/p1596122874213100

Environment:

• Kudo version (use kubectl kudo version): 0.15.0

this was fixed by #1629

<!-- Thanks for sending a pull request! Here are some tips for you:

1. If this is your first time, please read our contributor guidelines: https://github.com/kudobuilder/kudo/blob/main/CONTRIBUTING.md
2. Make sure you have added and ran the tests before submitting your PR
3. If the PR is unfinished, start it as a Draft PR: https://github.blog/2019-02-14-introducing-draft-pull-requests/ -->

What this PR does / why we need it:

The allowlist in verifier got out of sync with reality and package create rejects an otherwise valid package.

<!-- *Automatically closes linked issue when PR is merged. Usage: Fixes #<issue number>, or Fixes (paste link of issue). --> Fixes #

yeah, the startup probe is 1.16+

<!-- Thanks for sending a pull request! Here are some tips for you:

1. If this is your first time, please read our contributor guidelines: https://github.com/kudobuilder/kudo/blob/main/CONTRIBUTING.md
2. Make sure you have added and ran the tests before submitting your PR
3. If the PR is unfinished, start it as a Draft PR: https://github.blog/2019-02-14-introducing-draft-pull-requests/ -->

What this PR does / why we need it: This is part of the solution for #1625

I ended up using startup probe instead of readiness because that's run only when manager starts, we don't need to poll the endpoint when manager is running.

so the solution I am leaning to here is:

• introduce a startup check waiting for webhook port to be bound
• change the --wait behavior so that it reads for pod phase 'ready'

@ncdc are you still working on this? I've just spent many hours trying to figure out a nice way how to create such readiness check from outside that I am starting to think it would be easier to implement it within controller-runtime

<!-- Thanks for sending a pull request! Here are some tips for you:

1. If this is your first time, please read our contributor guidelines: https://github.com/kudobuilder/kudo/blob/main/CONTRIBUTING.md
2. Make sure you have added and ran the tests before submitting your PR
3. If the PR is unfinished, start it as a Draft PR: https://github.blog/2019-02-14-introducing-draft-pull-requests/ -->

What this PR does / why we need it: This covers regression in #1596

It had to be e2e because in integration, the deletion actually never happens because the GC controller is not running.

@kensipe what's the use case, just wondering? why using k8s built in readiness + pod states are not enough?

I think the correct solution is to add readiness/liveness check and then correctly assert --wait on phase == ready not pod running as it's doing right now (incorrectly).

<!-- Please only use this template for submitting enhancement requests. Implementing your enhancement will follow the KEP process: https://github.com/kudobuilder/kudo/blob/main/keps/0001-kep-process.md -->

What would you like to be added:

kudo git:(av/delete-apply-delete-test) ✗ ./bin/kubectl-kudo init --version 0.15.0
$KUDO_HOME has been configured at /Users/alenavarkockova/.kudo
:white_check_mark: installed crds
:white_check_mark: installed namespace
Error: error installing: service account: serviceaccounts "kudo-manager" is forbidden: unable to create new content in namespace kudo-system because it is being terminated

This should ideally fail pre-install and not end up being partial install that one needs to manually clean up.

Why is this needed:

this really bugs me a lot, I am used to being able to get the yaml out of the CLI and hitting this all the time :(

./bin/kubectl-kudo init --version 0.15.0 -o yaml --dry-run
Errors
CRD operators.kudo.dev is already installed. Did you mean to use --upgrade?
Error: failed to verify installation requirements

@nfnt oh right, there could be multiple resources in an assert, correct? Yeah, let's change that

<!-- Please only use this template for submitting enhancement requests. Implementing your enhancement will follow the KEP process: https://github.com/kudobuilder/kudo/blob/main/keps/0001-kep-process.md -->

What would you like to be added: Integration tests currently run following command:

commands:
  - command: |-
      sh -c '
      KUDO_CERT_DIR="./test/cert" ./bin/manager
      '
    background: true
  - command: sleep 5

If this command fails, e.g. because of Unable to run the manager: listen tcp :443: bind: permission denied the test suite is still run and this error is burried somewhere.

Two enhancements from this:

• do not use sleep and introduce a proper wait on manager being up
• change the port from 443 to something an unprivileged used can bind to

Why is this needed:

<!-- Thanks for sending a pull request! Here are some tips for you:

1. If this is your first time, please read our contributor guidelines: https://github.com/kudobuilder/kudo/blob/main/CONTRIBUTING.md
2. Make sure you have added and ran the tests before submitting your PR
3. If the PR is unfinished, start it as a Draft PR: https://github.blog/2019-02-14-introducing-draft-pull-requests/ -->

What this PR does / why we need it: This fixes a bug when a sequence of apply-delete-apply meant that the resource did not exist in the end because we did not wait for item to be deleted out of the cache of the client we're using. Details are in #1596

The solution introduces "health check" for deletion which queries client until it's deleted. Instead of poll & wait and blocking the worker thread we're relying on reconciliation loop being re-trigerred. We now reschedule reconciliation when plan is running to prevent stalling. A simple backoff mechanism implemented as well.

<!-- *Automatically closes linked issue when PR is merged. Usage: Fixes #<issue number>, or Fixes (paste link of issue). --> Fixes #1596

What happened: I have a plan where I want to reapply a pod and it’s configmaps, My steps are:

1. Delete a Pod
2. Delete a ConfigMap
3. Apply a ConfigMap
4. Apply the Pod The problem is that step 3 doesn’t reapply my ConfigMap, so then step 4 never runs but yet my operator plan reports a full COMPLETED steps and plan. All phases and steps in my plan are set to serial.

What you expected to happen: Step 3 above to reapply my ConfigMap

How to reproduce it (as minimally and precisely as possible): Create two tasks for a Pod and ConfigMap, one to Apply and one to Delete the same Kube manifest.

Then a plan like this:

  redeploy-connectors:
    strategy: serial
    phases:
    - name: connectors-stop
      strategy: serial
      steps:
      - name: stop-connectors
        tasks:
        - connectors-stop
      - name: delete-bootsrap
        tasks:
        - connectors-bootstrap-delete
    - name: connectors-redeploy
      strategy: serial
      steps:
      - name: redeploy-connector-configmaps
        tasks:
        - connectors-bootstrap
      - name: restart-connectors
        tasks:
        - connectors-start

Anything else we need to know?:

Environment:

• Kubernetes version (use kubectl version): Client v1.17.0, Server v1.18.3
• Kudo version (use kubectl kudo version): 0.15.0
• Operator: Custom
• Cloud provider or hardware configuration: minikube running in VirtualBox on Mac

I tried to clarify, let me know if it's better

<!-- Thanks for sending a pull request! Here are some tips for you:

1. If this is your first time, please read our contributor guidelines: https://github.com/kudobuilder/kudo/blob/main/CONTRIBUTING.md
2. Make sure you have added and ran the tests before submitting your PR
3. If the PR is unfinished, start it as a Draft PR: https://github.blog/2019-02-14-introducing-draft-pull-requests/ -->

What this PR does / why we need it: This covers regression in #1596

@nfnt so what is the plan for older CLIs? Will the old repo still be updated for a while? Or are we pretty much decommissioning it?

@nfnt oh yeah, integration test covering the regression is definitely a good idea. I'll work on that!

deploy-clean is broken now. I hesitate to remove it but it has been broken for some time which signals that it isn't used. IF we want it than... what is recommended to add for the controller version?

Regardless... deploy-clean should NOT be apart of clean IMO.

Signed-off-by: Ken Sipe [email protected]

<!-- Thanks for sending a pull request! Here are some tips for you:

1. If this is your first time, please read our contributor guidelines: https://github.com/kudobuilder/kudo/blob/main/CONTRIBUTING.md
2. Make sure you have added and ran the tests before submitting your PR
3. If the PR is unfinished, start it as a Draft PR: https://github.blog/2019-02-14-introducing-draft-pull-requests/ -->

What this PR does / why we need it: This fixes a bug when a sequence of apply-delete-apply meant that the resource did not exist in the end because we did not wait for item to be deleted out of the cache of the client we're using. Details are in #1596

The solution introduces "health check" for deletion which queries client until it's deleted. Instead of poll & wait and blocking the worker thread we're relying on reconciliation loop being re-trigerred. We now reschedule reconciliation when plan is running to prevent stalling. A simple backoff mechanism implemented as well.

<!-- *Automatically closes linked issue when PR is merged. Usage: Fixes #<issue number>, or Fixes (paste link of issue). --> Fixes #1596

oh I see, so I think the proper fix then is to create a plan with this task https://github.com/kudobuilder/operators/pull/283/files#diff-03f33d8320fe5aa10c3409ce4fc7189bL37

how come you can drop this? 🤔

is Equal and DeepEqual the same thing?

what changed here? that we can do it now...

Signed-off-by: Alena Varkockova [email protected]

<!-- Thanks for sending a pull request! Here are some tips for you:

1. If this is your first time, please read our contributor guidelines: https://github.com/kudobuilder/kudo/blob/main/CONTRIBUTING.md
2. Make sure you have added and ran the tests before submitting your PR
3. If the PR is unfinished, start it as a Draft PR: https://github.blog/2019-02-14-introducing-draft-pull-requests/ -->

What this PR does / why we need it: Fixes #1612

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security sensitive, please disclose it privately to a security contact: https://github.com/kudobuilder/kudo/blob/main/SECURITY_CONTACTS -->

What happened: ./bin/kubectl-kudo plan trigger --instance=test-operator-instance --name=xxx Triggered xxx plan for default/test-operator-instance instance

It also updates the CRD which it should not

What you expected to happen: Get an error that plan does not exist.

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

Signed-off-by: Alena Varkockova [email protected]

<!-- Thanks for sending a pull request! Here are some tips for you:

1. If this is your first time, please read our contributor guidelines: https://github.com/kudobuilder/kudo/blob/main/CONTRIBUTING.md
2. Make sure you have added and ran the tests before submitting your PR
3. If the PR is unfinished, start it as a Draft PR: https://github.blog/2019-02-14-introducing-draft-pull-requests/ -->

What this PR does / why we need it: Fixes #1612

Just came by this PR. Why did we introduce new annotation, just wondering? Can't we use something that we already. use for all the other objects in enhancer? Like e.g. kudo.HeritageLabel ? 🤔 sorry if you already had this discussion in the past :)

I am no sure that's a good idea or that would be my last resort. We could reschedule reconciliation after failed delete check and even maybe leverage the RequeueAfter https://github.com/kubernetes-sigs/controller-runtime/blob/fc39662443b99ad0dcab22001571ccb9bc5b7960/pkg/reconcile/reconcile.go#L32 🤔

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security sensitive, please disclose it privately to a security contact: https://github.com/kudobuilder/kudo/blob/main/SECURITY_CONTACTS -->

What happened: ./bin/kubectl-kudo plan trigger --instance=test-operator-instance --name=xxx Triggered xxx plan for default/test-operator-instance instance

What you expected to happen: Get an error that plan does not exist.

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

@ANeumann82 oh yeah, that part... I was also wondering what would be a good solution to that as we should be watching everything that package creates and it can create pretty much anything 🤔

@ANeumann82 isn't that basically what controller-runtime is doing though? it watches the resources and schedules reconciliation when the watch happens. What do you picture the watch triggering other than reconciliation? Just wondering 🤔

Okay, I think I understand what's going on. We have a plan that basically does this:

• create resource A1
• delete resource A1
• create resource A1

For resource deletion, we don't check for health, we assume that happened https://github.com/kudobuilder/kudo/blob/9db03a9f2be3d7bfe457ebc000881ad4433a27d4/pkg/engine/task/task_delete.go#L55

But I see that's not the case, I see that when I run in a debug it's actually doing:

• create resource A1
• delete resource A1
• PATCH resource A1 (it thinks A1 still exists!)

By the way - if I do sleep for couple of seconds after deletion, it all works so it's really about all that happening asynchronously and us proceeding to the next step too fast.

As a solution I would propose:

• add healthcheck for DeleteTask (it will query client.Get until it gets 404)
• add ConfigMap to Owns here so we get reconciliation request after it got deleted https://github.com/kudobuilder/kudo/blob/f2142a9e672b40dad0daac158b4572adcf6a7308/pkg/controller/instance/instance_controller.go#L112

Question: should we do the same for create? 🤔 or is that synchronous and can you always do client.Get after create and always get your object?

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security sensitive, please disclose it privately to a security contact: https://github.com/kudobuilder/kudo/blob/main/SECURITY_CONTACTS -->

What happened:

./kubectl-kudo_0.15.0_darwin_x86_64 init -o yaml --dry-run
Errors
failed to detect any valid cert-manager CRDs. Make sure cert-manager is installed.
Error: failed to verify installation requirements

What you expected to happen: Dry run to pass

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

duplicate of #1590

there's challenge with cert-manager related resources. @ANeumann82 can fill in the details since he pointed it out

@dboyleitrs okay it looks like I was able to reproduce, thanks for reporting it! I'll let you know once I know more :)

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security sensitive, please disclose it privately to a security contact: https://github.com/kudobuilder/kudo/blob/main/SECURITY_CONTACTS -->

What happened:

./kubectl-kudo_0.15.0_darwin_x86_64 init -o yaml --dry-run
Errors
failed to detect any valid cert-manager CRDs. Make sure cert-manager is installed.
Error: failed to verify installation requirements

What you expected to happen: Dry run to pass

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

With this change we support even k8s < 1.16 but at the same time we also support all following k8s versions. We should do this change when v1beta1 is not available and then talk about the support matrix.

Fixes #1577

Signed-off-by: Alena Varkockova [email protected]

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security sensitive, please disclose it privately to a security contact: https://github.com/kudobuilder/kudo/blob/main/SECURITY_CONTACTS -->

What happened:

When trying to run kubectl kudo init -v4 on Kubernetes 1.15.11, I get the following logs:

...
Try to retrieve cert-manager CRD certificates.cert-manager.io
Try to retrieve cert-manager CRD certificates.certmanager.k8s.io
Errors                                                                 
failed to detect any valid cert-manager CRDs. Make sure cert-manager is installed.
Error: failed to verify installation requirements

This is caused here because apiextensions.k8s.io/v1 isn't available until Kubernetes 1.16.0.

What you expected to happen:

w00p w00p it init'd properly!

How to reproduce it (as minimally and precisely as possible):

Run kubectl kudo init against a 1.15 cluster.

Environment:

• Kubernetes version (use kubectl version): client 1.16.6-beta.0, server 1.15.11-eks-af3caf
• Kudo version (use kubectl kudo version): 0.14.0
• Cloud provider or hardware configuration: EKS

<!-- Thanks for sending a pull request! Here are some tips for you:

1. If this is your first time, please read our contributor guidelines: https://github.com/kudobuilder/kudo/blob/main/CONTRIBUTING.md
2. Make sure you have added and ran the tests before submitting your PR
3. If the PR is unfinished, start it as a Draft PR: https://github.blog/2019-02-14-introducing-draft-pull-requests/ -->

What this PR does / why we need it:

Follow-up to https://github.com/kudobuilder/kudo/pull/1579

<!-- Thanks for sending a pull request! Here are some tips for you:

1. If this is your first time, please read our contributor guidelines: https://github.com/kudobuilder/kudo/blob/main/CONTRIBUTING.md
2. Make sure you have added and ran the tests before submitting your PR
3. If the PR is unfinished, start it as a Draft PR: https://github.blog/2019-02-14-introducing-draft-pull-requests/ -->

What this PR does / why we need it: Currently it is not required and yields the following error:

./bin/kubectl-kudo diagnostics collect
Collect Logs for 1 pods
Error: failed to get instance default/: resource name may not be empty

Signed-off-by: Andreas Neumann [email protected]

What this PR does / why we need it:

There's no need for this log - it might confuse people that this is something they need to fix or adjust. Maybe we should add a warning in the package verify if a Dummy Task is used, as it should be only used for debugging though.

is it good idea to have a default with invalid email address? 🤔 should we at least go for something valid but nonexistent (probably?)

could you just put a comment here that interactive does not need name because we use default name that can be changed or sth like that? It was not obvious to me and I actually had to test it to understand what's going on

should we note somewhere which version of goreleaser we currently support? Is there a way to somehow "fix" it like if we would be using go.mod or other dependency resolution thing?