You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
talm template --set floatingIP=192.168.1.1 (and talm apply --set ...) feed values through Helm's strvals.ParseInto, which type-coerces ambiguous values. An IP literal like 192.168.1.1 is parsed by Helm as a float-shaped token (multiple dots, no leading +/-). The exact behaviour is library-version-dependent but unsafe by default.
Operators who scripted --set floatingIP=... may get unintended type coercion silently; the chart sees a numeric value where it expected a string, and Sprig's toString round-trip may bake in formatting differences (192.168.1.1 vs 192168.0011 if the parser landed on a float).
With the post-#163 chart, the fail-fast validator catches the malformed value:
talm: floatingIP "0700" is not a valid IPv4 / IPv6 literal. Edit values.yaml and re-run.
Without the validator (older preset), the value goes through as an integer literal 700 (octal interpretation suppressed by Sprig's toString, but the type information is already lost).
For numeric-shaped non-IP keys (--set replicas=1.0), Helm's coercion is silent — no validator catches it.
Workaround
Use --set-string for any value where type-stability matters:
--set-string skips type coercion and stores the value as a string verbatim.
Expected
Document loudly in the --set help text and README: for IP / hostname / version literals, use --set-string to avoid type coercion. Concrete examples in the help text.
Most operators copy commands from internal runbooks / Slack. A --set floatingIP=10.17.100.10 example will be pasted-and-pasted. Each fork of the value carries the float-coercion risk. Documenting the gotcha + the --set-string escape hatch is one README paragraph.
Surfaced during the dev17 manual test plan exercise (J0-1).
Problem
talm template --set floatingIP=192.168.1.1(andtalm apply --set ...) feed values through Helm'sstrvals.ParseInto, which type-coerces ambiguous values. An IP literal like192.168.1.1is parsed by Helm as a float-shaped token (multiple dots, no leading+/-). The exact behaviour is library-version-dependent but unsafe by default.Operators who scripted
--set floatingIP=...may get unintended type coercion silently; the chart sees a numeric value where it expected a string, and Sprig'stoStringround-trip may bake in formatting differences (192.168.1.1vs192168.0011if the parser landed on a float).Reproduction
With the post-#163 chart, the fail-fast validator catches the malformed value:
Without the validator (older preset), the value goes through as an integer literal
700(octal interpretation suppressed by Sprig'stoString, but the type information is already lost).For numeric-shaped non-IP keys (
--set replicas=1.0), Helm's coercion is silent — no validator catches it.Workaround
Use
--set-stringfor any value where type-stability matters:--set-stringskips type coercion and stores the value as a string verbatim.Expected
--sethelp text and README: for IP / hostname / version literals, use--set-stringto avoid type coercion. Concrete examples in the help text.floatingIP/endpointvalidators and coerce-through-toString as the first step, the way PR fix(charts): pin Layer2VIPConfig to subnet-matching link, not default route #163 already does for nil and integer values.Why this matters
Most operators copy commands from internal runbooks / Slack. A
--set floatingIP=10.17.100.10example will be pasted-and-pasted. Each fork of the value carries the float-coercion risk. Documenting the gotcha + the--set-stringescape hatch is one README paragraph.Surfaced during the dev17 manual test plan exercise (J0-1).