Deployment not working out of the box

[hown3d]

Description

The example deployment for cloud-controller-manager is not working as the image does not exist.
Also it does not tolerate the node.cloudprovider.kubernetes.io/uninitialized taint which is set by kubelet if it has the flag --cloud-provider=external set.

Steps to reproduce

$ kubectl apply -k deploy/
$ kubectl describe pod <cloud-controller-manager>
Warning  FailedScheduling  1s    default-scheduler  0/3 nodes are available: 3 node(s) had untolerated taint(s).
 no new claims to deallocate, preemption: 0/3 nodes are available: 3 Preemption is not helpful for scheduling.

# Adding toleration
$ kubectl describe pod <cloud-controller-manager>
  Warning  Failed     6s (x3 over 50s)   kubelet            spec.containers{stackit-cloud-controller-manager}: Failed to p
ull image "ghcr.io/stackitcloud/cloud-provider-stackit/cloud-controller-manager:release-v1.34": rpc error: code = NotFound
 desc = failed to pull and unpack image "ghcr.io/stackitcloud/cloud-provider-stackit/cloud-controller-manager:release-v1.3
4": failed to resolve reference "ghcr.io/stackitcloud/cloud-provider-stackit/cloud-controller-manager:release-v1.34": ghcr
.io/stackitcloud/cloud-provider-stackit/cloud-controller-manager:release-v1.34: not found

Actual behavior

Deployment is not starting without applying patches

Expected behavior

Expect the deployment to work like it is in the repository. For releases I would expect to get the matching version.

Environment

• Kubernetes version: irrelevant
• Version of the cloud-provider-stackit: main

Additional information

Feel free to add any additional information here.

/kind bug

[corioliskraft]

@hown3d about the image tag: release-v1.34, release-v1.35 and release-v1.36 do not exist in the registry, for the CCM image and for the CSI image. The last branch tag that exists is release-v1.33. The manifests on all three release branches point to release-v1.34, so each supported version is affected.

Proposal: build the branch tag again for the current release branches. hack/build.sh:40 already adds PULL_BASE_REF to the tag list, so this needs no change in deploy/ or docs/, and no manual tag update at each release.

Did you stop this build on purpose? If yes, there is an alternative way: put the semver tag of each release branch in the manifests. Or, if you prefer a different method, please let me know which one.

The toleration part of this report is in #1517.

Thanks.

[breuerfelix]

@corioliskraft the tags exist in the registry, but inside the -dev version of the images since they always target the lastest commit of the branch so they are more likely to be development images.

We thought about a different approach: creating new tags for the minor versions e.g. v1.35, v1.36, ... and always use the latest patch version for that.
Afterwards use the currently latest kubernetes version and reference that in the deployment manifests.
We only would need to update the deployment manifest with new kubernetes versions, which does not happen that often.

[corioliskraft]

@breuerfelix Got it, thanks, then the suggestion is: you create respectively v1.34, v1.35 and v1.36 for branches in stackit-csi-plugin and cloud-controller-manager, after that I make four PRs (release-v1.34, release-v1.35, release-v1.36 and main) with update to the following files:

deploy/cloud-controller-manager/deployment.yaml:28
deploy/csi-plugin/nodeplugin.yaml:56
deploy/csi-plugin/controllerplugin.yaml:96
docs/deployment.md:84

Makes sense?

[dergeberl]

Both mentioned issues are now fixed. I will therefore close the issue.