--set parses number only values as float64

[databus23]

I just noticed that something like helm install --set tag=20161216 ends up in scientific notation in the template and thats because {{ typeOf .Value.tag }} yields float64.

Thats even true for small integers like helm install --set tag=1 --> float64.

This is happening with helm 2.1.0

[technosophos]

Does it work differently if you do --set tag=\"1\"?

[technosophos]

Thanks to @chancez we know the exact problem: During the conversions to and from JSON done by ghodss/yaml, integers are being cast into float64s to represent Javascript's numeric type. This is causing all integers above a certain value to be represented in scientific notation.

[ipedrazas]

I've been bitten by the same problem. The way of getting over the hump (or the bug) is to do this:

--set bignumber=\\"a185576882739235744\\"

[technosophos]

Another workaround we have used is to do stuff like this:

--set port=":1234567"

Then in the template:

{{ .Values.port | replace ":" "" }}

[databus23]

Yuck! 😷

[jemc]

This is a heck of a pain, and @ipedrazas' workaround doesn't seem to work for me, or any other combination of quoting/escaping I've tried.

I'm not quite willing yet to swallow my pride and try @technosophos' ugly hack...

For now I'm hacking around this by expanding my deploy script to write the data as yaml to a temporary file and use that as a -f argument.

[Smana]

I'm facing the same issue from time to time for the image tag.
I'll try to use one of these workaround. I hope it will be fixed soon :)

[holybit]

In my case, seeing this below on --set image.tag=5997578:

$ kubetctl describe po msj-treasure-map-msj-treasure-map-192172122-dnb80
...
Events:
  Type     Reason         Age               From                                    Message
  ----     ------         ----              ----                                    -------
  Normal   Scheduled      1m                default-scheduler                       Successfully assigned msj-treasure-map-msj-treasure-map-192172122-dnb80 to ip-10-253-13-113.ec2.internal
  Warning  InspectFailed  15s (x9 over 1m)  kubelet, ip-10-253-13-113.ec2.internal  Failed to apply default image tag "596297932419.dkr.ecr.us-east-1.amazonaws.com/msj-trmap-uwsgi:5.997578e+06": couldn't parse image reference "596297932419.dkr.ecr.us-east-1.amazonaws.com/msj-trmap-uwsgi:5.997578e+06": invalid reference format
  Warning  InspectFailed  15s (x9 over 1m)  kubelet, ip-10-253-13-113.ec2.internal  Failed to apply default image tag "596297932419.dkr.ecr.us-east-1.amazonaws.com/msj-trmap-nginx:5.997578e+06": couldn't parse image reference "596297932419.dkr.ecr.us-east-1.amazonaws.com/msj-trmap-nginx:5.997578e+06": invalid reference format
  Warning  FailedSync     15s (x9 over 1m)  kubelet, ip-10-253-13-113.ec2.internal  Error syncing pod, skipping: [failed to "StartContainer" for "msj-treasure-map-uwsgi" with InvalidImageName: "Failed to apply default image tag \"596297932419.dkr.ecr.us-east-1.amazonaws.com/msj-trmap-uwsgi:5.997578e+06\": couldn't parse image reference \"596297932419.dkr.ecr.us-east-1.amazonaws.com/msj-trmap-uwsgi:5.997578e+06\": invalid reference format"
, failed to "StartContainer" for "msj-treasure-map-nginx" with InvalidImageName: "Failed to apply default image tag \"596297932419.dkr.ecr.us-east-1.amazonaws.com/msj-trmap-nginx:5.997578e+06\": couldn't parse image reference \"596297932419.dkr.ecr.us-east-1.amazonaws.com/msj-trmap-nginx:5.997578e+06\": invalid reference format"

$ helm version                                                                                                                                                                             
Client: &version.Version{SemVer:"v2.5.1", GitCommit:"7cf31e8d9a026287041bae077b09165be247ae66", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.5.1", GitCommit:"7cf31e8d9a026287041bae077b09165be247ae66", GitTreeState:"clean"}

[BrendanBall]

I am also experiencing the same problem on helm 2.6.2.

Client: &version.Version{SemVer:"v2.6.2", GitCommit:"be3ae4ea91b2960be98c07e8f73754e67e87963c", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.6.2", GitCommit:"be3ae4ea91b2960be98c07e8f73754e67e87963c", GitTreeState:"clean"}

[jayste]

• 1

Stripping YAML down to JSON removes a lot of information, most type related. Means you can't type check values pre-deploy.

I guess this can be resolved by moving to a different yaml library. Maybe this one: https://github.com/go-yaml

[schnerring]

@joejulian I tried your example and have mixed results.

version.BuildInfo{Version:"v3.8.0", GitCommit:"d14138609b01886f544b2025f5000351c9eb092e", GitTreeState:"clean", GoVersion:"go1.17.5"}

Running helm template foo . --set foo=20161216 --show-only templates/foo.yaml:

---
# Source: foo/templates/foo.yaml
value: 20161216
type: int64

Running helm template foo . --show-only templates/foo.yaml when setting foo: 20161216 inside values.yaml:

---
# Source: foo/templates/foo.yaml
value: 2.0161216e+07
type: float64

Interestingly multiplying by 1 "fixes" the issue:

value: {{ mul .Values.foo 1 }}
type: {{ typeOf .Values.foo }}

The type still is float64, however:

---
# Source: foo/templates/foo.yaml
value: 20161216
type: float64

[thatsnotamuffin]

@joejulian I'm having this issue right now with v3.11.2 using a value of 93572e3 during the helm template command I'm getting this as the image tag 9.3572e+07.

I'm not seeing how its resolved or a workaround using helm install or helm upgrade. I'd rather avoid a hacky workaround if I can.

[Mo0rBy]

I'm having this exact same issue using v3.12.2.

My values.yaml file contains : servicePort: 1433 and I am attempting to create a database url using the printf function, something like this:
{{ printf "jdbc:sqlserver://%s:%d" .Values.myString .Values.servicePort }}

I get the following result: jdbc:sqlserver://psdt-mssql:%!d(float64=1433)

Happy to create a new issue for this as this is an old thread, but if I do, can it actually be fixed??

I've skirted around the issue by changing my values.yaml file to be servicePort: "1433" and having {{ printf "jdbc:sqlserver://%s:%s" .Values.myString .Values.servicePort }}, but I'd really prefer just to put the number in instead of a string. It just seems logical to be able to do it this way.

[jhonsanchez]

{{ printf "jdbc:sqlserver://%s:%d" .Values.myString .Values.servicePort }}

you could try this:
{{ printf "jdbc:sqlserver://%s:%s" .Values.myString (.Values.servicePort | toString) }}

[myron0815]

Is this something we should reopen / create a new issue?

Helm 3.11/3.12/3.13 all render here numbers >= 1.000.000 as exponent, and all values are float64
Is there any use-case for this i'm failing to see?

Treating all numbers as String could not have been the intention of the creators :)
And multiplying by one, well, yes, it does work, but... yuck.

[sarasensible]

Vote for reopening - just hit this too.

[judaschwartz]

you could try this: {{ printf "jdbc:sqlserver://%s:%s" .Values.myString (.Values.servicePort | toString) }}

This works no need to reopen this

[ivankatliarchuk]

Simple test

input

test1: v11724e28
test2: 11724e28
test3: 2.10.6
test4: v2.10.6

helm template

test1: {{ .Values.test1 }}
test1Type: {{ typeOf .Values.test1 }}
test2: {{ .Values.test2 }}
test2Type: {{ typeOf .Values.test2 }}
test3: {{ .Values.test3 }}
test3Type: {{ typeOf .Values.test3 }}
test4: {{ .Values.test4 }}
test4Type: {{ typeOf .Values.test4 }}

output for a helm template command

---
# Source: test-helm/templates/test.yaml
test1: v11724e28
test1Type: string
test2: 1.1724e+32
test2Type: float64
test3: 2.10.6
test3Type: string
test4: v2.10.6
test4Type: string

Can we have it fixed at some point?

[nikicat]

@ivankatliarchuk Isn't it an expected behavior? Yaml parser sees 11724e28 as a float.

[Mo0rBy]

@ivankatliarchuk Isn't it an expected behavior? Yaml parser sees 11724e28 as a float.

This is exactly what this thread is about no? Why does 11724e28 get parsed as a float when the other cases are all string. I believe the reason it is being parsed as a float is because it is reading it as scientific number notation (e28 means x10^28 (multiply by 10 to the power of 28)), but I really hate that it's not consistent, and I don't think many users (if any) need to parse things in scientific number notation when using yaml.

[Mo0rBy]

Also, within my own specific issue, I was using %d to indiciate that I have a number value, I want to put that into the string format, but it would print as %!d(float64=1433) rather than putting 1433 into that position.

[nikicat]

This is exactly what this thread is about no?

I suppose this thread is about the command line argument parser, not the YAML parser.

[Mo0rBy]

This is exactly what this thread is about no?

I suppose this thread is about the command line argument parser, not the YAML parser.

Ah right sorry, I misinterpreted what you meant

[dberardo-com]

after reading through all this discussion i am stil confused ... is there any workaround so far ? like using "| quote" ? or what ?

[sebastianpiskorski]

after reading through all this discussion i am stil confused ... is there any workaround so far ? like using "| quote" ? or what ?

| quote doesn't work

[MalteMagnussen]

Vote for reopening. Just saw this as well.

deployment.yaml:

          image: "{{ .Values.sidecar.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"

with values.yaml:

image:
  tag: 87940363

becomes desired manifest of:

        - image: 'redacted-image-name:8.7940363e+07'

---

Using this does not work, because as soon as the tag changes to something that isn't an int, we have a helm problem.

          image: "{{ .Values.sidecar.image.repository }}:{{ .Values.image.tag | int }}"