GoogleContainerTools / GoogleContainerTools/skaffold

k.kubectl.WaitForDeletions does bail on new CRDs

Open
#4,641 12 comments 4 reactions 0 assignees View on GitHub
area/deploy CRDs kind/bug priority/p3
Dominant language
Go
Stars
15.9k
Forks
1.7k
Avg merge
3d 9h
Merged PRs (30d)
10

Description

Unless switched off ...
```golang
func (c *CLI) WaitForDeletions(ctx context.Context, out io.Writer, manifests ManifestList) error {
if !c.waitForDeletions.Enabled {
return nil
}

[...]
```
... `WaitForDeletions` does perform `kubectl get` on the `manifests.Reader()`ed output.

**Given** the case, that `manifests.Reader()`ed output contains `CRD`s unbeknownst to the cluster, the call to `kubectl get` just bails without further due:

```golang
if err != nil {
return err
}
```

**However,** in the context of developing the k8s manifest of an application which include CRDs, one does not want to hit a cryptic error message which forces one to debug skaffold code to see what's going on.

**Therfore**, _either_ provide an actionable error message which instructs to disable `waitForDeletions` on the cli (eg. by parsing the kubectl error message), _or_ reconcile CRDs used in those manifests intelligently prior to proceeding with `WaitForDeletions`, _or_ filtering out non-available CRDs from the `manifests.Reader()`ed output.

Considerations: In the context and intent of `WaitForDeletions`, maybe filtering out those CRDs from the input manifest is the most consistent and safe solution, since at the and of `WaitForDeletions`, all resources shall be deleted anyway.

Here is the actual log snippet:

```console
exiting dev mode because first deploy failed: running [kubectl --context k3d-k3s-default get -f - --ignore-not-found -ojson]
- stdout: ""
- stderr: "error: unable to recognize \"STDIN\": no matches for kind \"ClusterIssuer\" in version \"cert-manager.io/v1alpha2\"\n"
- cause: exit status 1
```

Note, that it is deceiving that `--ignore-not-found` in
```golang
buf, err := c.RunOutInput(ctx, manifests.Reader(), "get", c.args(nil, "-f", "-", "--ignore-not-found", "-ojson")...)
```
apparently does _not_ apply to resource definitions, only to resources. Which, though deceiving, is kind of consistent - depending on the viewpoint.

/cc @dgageot - since you last modified those lines.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.