Controller no longer respecting CloudMapDNS.ttl value when creating cloudmap services

[seanr-cardless]

Describe the bug

cloudMapDNS.ttl is no longer correctly taken into account when creating cloudmap services.

Since this commit the helm template expects an int64 cloudMapDNS.ttl value instead of a float64.

This is probably related to known helm issues, where int values are being parsed and represented in float64 through scientific notation

• Setting large int64 values in values.yaml converts them to float64 helm/helm#11130
• --set parses number only values as float64 helm/helm#1707

Newly created cloudmap services are being created with the default ttl of 300, rather than a specified cloudMapDNS.ttl.

Steps to reproduce

• Deploy a new cloudmap service with a specified cloudMapDNS.ttl with a sample value (e.g. 5)

OR

1. Locally remove the output redirection to /dev/null in helm-lint.sh
2. Specify a cloudMap.ttl value of 5 in the test.yaml values file
3. Run ./test/helm/helm-lint.sh | grep "cloudmap" to see the helm output
   • There should be no output because cloudmapDNS.ttl is not included in the values file unless it is of type int64
4. Chane the int64 back to float64 in the deployment.yaml
5. Re-run ./test/helm/helm-lint.sh | grep "cloudmap"
   • You should now see --cloudmap-dns-ttl=5 in the output

Expected outcome
A concise description of what you expected to happen.

The appmesh controller deployment should use the cloudMapDNS.ttl specified in the values file

Environment

• App Mesh controller version 1.9.0
• Envoy version - 1.22.2
• Are you using any integrations? X-ray, Jaeger etc. If so versions? N/A
• Kubernetes version - 1.23
• Using EKS (yes/no), if so version? -Yes, 1.23

Additional Context:

N/A