Kubevious YAML parser sees hex numbers differently from Kubernetes, causing false positives.

[renaudguerin]

We're using Kustomize's configMapgenerator with a .env file that contains a variable whose value is a 128-bit number in hex format, like so :

test.env : FOO=0xABCDABCDABCDABCDABCDABCDABCDABCD

The generated configMap has the exact same string (no quotes) : FOO: 0xABCDABCDABCDABCDABCDABCDABCDABCD
It gets applied without any issues.

However kubevious lint doesn't like it : 🔴 Invalid type under "/data/FOO". Must be string.

It clearly parses it as a number (and I can't say it's wrong), but here's the thing : Kustomize doesn't, it sees it as a string already and doesn't add quotes to the output.
It gets more interesting : Kustomize (and also kubectl create configmap --from-env-file) behaves differently for hex strings up to 64-bit, and it does add quotes for those ! FOO=0xABCDABCDABCDABCD becomes FOO: "0xABCDABCDABCDABCD", probably because whatever YAML library it uses parses it as an int64.

This is inconsistent (if explainable) behavior from Kustomize and I'm going to report it, but that doesn't solve my immediate problem : if I add double quotes to the source variable, Kustomize will add its own single quotes to that in the output (e.g. FOO: '"0xABCDABCDABCDABCD"'). Kubevious will be happy but our application may require changes to handle that.

At the end of the day, it seems there's a discrepancy between Kubevious CLI's YAML parser and Kubernetes regarding these large hex strings, so it would be great if you could align that.

In the meantime, can you think of a workaround or a way to selectively disable this check ?

Thanks

[rubenhak]

@renaudguerin, This was a rare find. I looked to your submission in kustomize repo. See my comment. I don't think I have a good solution here. Kubevious follows and validates the API spec. Don't thin we should mask a bug with another one. Either way you should not be using numbers (even hex) in ConfigMap, maybe worth editing your manifests to use strings.

[renaudguerin]

Kubevious follows and validates the API spec. Don't thin we should mask a bug with another one

That's understandable (even though one could argue a validator should follow the target implementation as closely as possible bug for bug, not just the spec)
Can this check be selectively disabled perhaps ?

Either way you should not be using numbers (even hex) in ConfigMap, maybe worth editing your manifests to use strings.

That's the problem : Kubernetes sees them as strings already but Kubevious doesn't.
If I add quotes around the value in the source .env, configmapGenerator will add single quotes to that and the original quotes will end up in the env variable consumed by the application. Of course we could strip them there, but it's not ideal to require app changes just because we can't generate a value in the desired format.