Open spatterIight opened 1 day ago
This is a limitation of yaml syntax. If you need double quotes to come through in a string value you would have to do something like repo2-storage-verify-tls: '"n"'
or repo2-storage-verify-tls: "\"n\""
.
This is a limitation of yaml syntax. If you need double quotes to come through in a string value you would have to do something like
repo2-storage-verify-tls: '"n"'
orrepo2-storage-verify-tls: "\"n\""
.
This does not work, even with these escapes applied the variable is not correct:
Actual value:
repo2-storage-verify-tls: "\"n\""
OR repo2-storage-verify-tls: '"n"'
Value after passing through yaml.dump
:
repo2-storage-verify-tls: '"n"'
In this case Helm chart does NOT complain about the datatype -- but the variable still does not have the right value so the pod fails:
+ pgbackrest restore --type=time '--target=2024-09-20 12:00:00-04' --stanza=db --pg1-path=/pgdata/pg14 --repo=2 --delta --target-action=promote --link-map=pg_wal=/pgdata/pg14_wal
ERROR: [032]: boolean option 'repo2-storage-verify-tls' must be 'y' or 'n'
Thank you for the response 🫡 ultimately my main goal here is to simply document this issue in-case someone else has the same one -- took me forever to figure out what was happening.
SUMMARY
When using the
kubernetes.core.helm
module with therelease_values
parameter it is possible to encounter an issue stemming from filtering that occurs in theyaml.dump
operation.The
yaml.dump
operation associated withrelease_values
is on this line of code.The filtering applied by
yaml.dump
removes single and double quotes from variables. This causes an issue with certain helm charts that require specific values to be strings and not booleans.For example:
In the above error the CrunchyData postgres-operator chart requires that
repo2-storage-verify-tls
be a string -- butyaml.dump
has converted it to a boolean.Actual value:
repo2-storage-verify-tls: "n"
Value after passing through
yaml.dump
:repo2-storage-verify-tls: n
ISSUE TYPE
COMPONENT NAME
kubernetes.core.helm
ANSIBLE VERSION
COLLECTION VERSION
CONFIGURATION
OS / ENVIRONMENT
STEPS TO REPRODUCE
EXPECTED RESULTS
I expected
release_values
to preserve the Ansible variable I passed into it without applying any filtering to it. If I wanted to apply filtering to it I would use theto_nice_yaml
filter before handing it off to the Helm module.ACTUAL RESULTS
What actually happened is my variable got converted from a
string
to aboolean
Workaround
As a workaround it is possible to use
values_files
instead ofrelease_values
-- this bypasses the filtering operation.Thanks !