-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The Ansible "markUnsafe" option should mark more things as unsafe #5160
The Ansible "markUnsafe" option should mark more things as unsafe #5160
Comments
Encountered also this issue with fields inside annotations. So I would also mark as unsafe all the CR fields, and not only the spec. PS: The markUnsafe parameter doesn't seem to be documented today. |
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
/remove-lifecycle stale |
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
/lifecycle frozen |
I think we hit this same issue. |
Bug Report
What did you do?
I added
markUnsafe: true
towatches.yaml
and created a k8s resource containing strings that look like Jinja templates. I tried to access the_<group>_<kind>
var to retrieve a field understatus
that I had previously written.What did you expect to see?
I should be able to access data normally in the operator-provided
_<group>_<kind>
var when it contains Jinja-like data and havemarkUnsafe: true
set.What did you see instead? Under which circumstances?
Ansible blows up with a template error when it encounters the Jinja-like data contained in the k8s resource.
Environment
Operator type:
Kubernetes cluster type:
EKS
$ operator-sdk version
v1.7.2
Possible Solution
Make
markUnsafe: true
also apply to the_<group>_<kind>
magic variable (and perhaps any other magic variables).Additional context
I was able to work around this by using the
k8s_info
module to query the resource rather than using the operator-provided_<group>_<kind>
var. Values returned from module invocations are treated as unsafe by default by Ansible.The text was updated successfully, but these errors were encountered: