eksctl update addon does nothing

[MartinEmrich]

What were you trying to accomplish?

after control plane update, update addons as well:

./eksctl update addon -f eksctl-ClusterConfig.yaml --force --wait
2022-08-02 11:34:17 [ℹ]  Kubernetes version "1.22" in use by cluster "xxx"
2022-08-02 11:34:18 [ℹ]  updating addon
2022-08-02 11:34:28 [ℹ]  addon "vpc-cni" active
2022-08-02 11:34:29 [ℹ]  updating addon
2022-08-02 11:34:39 [ℹ]  addon "coredns" active
2022-08-02 11:34:40 [ℹ]  updating addon
2022-08-02 11:34:51 [ℹ]  addon "kube-proxy" active

relevant portion of my config file:

addons:
  - name: vpc-cni
  - name: coredns
  - name: kube-proxy

What happened?

Nothing, the version stayed the same.

How to reproduce it?

• have a cluster with non-current addon versions
• run above command

Versions

eksctl version: 0.107.0
kubectl version: v1.24.2
OS: linux```

I had expected this to just update the addons to the standard versions respectively. I assume --version latest will use the latest version, which is often ahead of the standard/recommended addon version.

[nikimanoledaki]

Hi @MartinEmrich, you need to declaratively set the version, like in the example below. When a version is not set, it preserves the existing version.

addons:
  - name: vpc-cni
    version: latest
  - name: coredns
    version: latest
  - name: kube-proxy
    version: latest

I hope this helps :)

We added some helpful logs around this for when addon.Version == nil but since it is not in the output that you provided, that is a bug. 🤔 I think it is because we are setting the version here so it is never "". Someone from the team will have a look at this soon!

[MartinEmrich]

Hello @nikimanoledaki!

That makes sense. Is there an alias for the "current" or "recommended" version similar to latest for the latest version? In the Web UI, AWS makes that distinction, and as I understand it, it is recommended to use that version instead of the latest version for production workloads.

As for the missing log line: I am not a Go developer, but could it be that in the line you linked to, the comparison fails as it is not an empty string (""), but a null value (nil)?