ADDITIONAL_ENI_TAGS : aws-node env gets initialized but cni fails to parse the ENI Tags

[kumarpmd]

What happened:
AWS EKS Cluster v1.20 cluster was deployed with default cni. cni was then patched to v1.8.0-eksbuild.1, that allows use of the custom tags for eni.
The upgrade was successful, however the supplied custom tags are not getting parsed successfully. Let us know if there is an issue how values were supplied, or if I am missing any required flags..

Patch deployment -

kubectl set env ds aws-node -n kube-system ADDITIONAL_ENI_TAGS={"AppId":"A99999"}
kubectl rollout restart daemonset aws-node -n kube-system
daemonset.apps/aws-node restarted

Error : /host/var/log/aws-routed-eni/ipamd.log-

{"level":"warn","ts":"2021-06-30T18:21:27.177Z","caller":"awsutils/awsutils.go:339","msg":"failed to parse additional ENI Tags from env ADDITIONAL_ENI_TAGS due to invalid character 'A' looking for beginning of value"}

Environment:

• Kubernetes version (use kubectl version):

• CNI Version
  v1.8.0-eksbuild.1

• OS (e.g: cat /etc/os-release):
  NAME="Amazon Linux"
  VERSION="2"
  ID="amzn"
  ID_LIKE="centos rhel fedora"
  VERSION_ID="2"
  PRETTY_NAME="Amazon Linux 2"
  ANSI_COLOR="0;33"
  CPE_NAME="cpe:2.3:o:amazon:amazon_linux:2"
  HOME_URL="https://amazonlinux.com/"

• Kernel (e.g. uname -a):
  Linux ip-10-247-25-195.awstrp.net 5.4.117-58.216.amzn2.x86_64 Initial commit of amazon-vpc-cni-k8s #1 SMP Tue May 11 20:50:07 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

[achevuru]

@kumarpmd Can you try kubectl set env ds aws-node -n kube-system ADDITIONAL_ENI_TAGS={\"AppId\":\"A99999\"}?

[achevuru]

@kumarpmd I tried with kubectl set env ds aws-node -n kube-system ADDITIONAL_ENI_TAGS={\"AppId\":\"A99999\"} and that worked fine for me. Closing the issue, feel free to reopen if you've any further questions.

[jayanthvn]

We might need to update our documentation?

[achevuru]

Doc has correct format specified. More to do with shell specific behavior when we try to set it directly.

[jayanthvn]

Ahh I see :)

[kumarpmd]

@achevuru Thank you. it was the quotes. Issue resolved once the quotes were handled. You were right, the kubectl was executed directly using a local-exec resolving from vars. However, I do agree with @jayanthvn in that a single liner in the documentation would have saved time troubleshooting. Thank you both..