Skip to content
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.

Sign up for GitHub

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

Jump to bottom

The Ansible "markUnsafe" option should mark more things as unsafe #5160

Closed
agaffney opened this issue Aug 18, 2021 · 6 comments · Fixed by #6376 · May be fixed by element-hq/operator-sdk#1
Closed

The Ansible "markUnsafe" option should mark more things as unsafe #5160

agaffney opened this issue Aug 18, 2021 · 6 comments · Fixed by #6376 · May be fixed by element-hq/operator-sdk#1
Assignees
@fabianvf
Labels
language/ansible Issue is related to an Ansible operator project lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. triage/support Indicates an issue that is a support question.
Milestone
Backlog

Comments

@agaffney
Copy link
Contributor

agaffney commented Aug 18, 2021 •
edited
Loading

Bug Report

What did you do?

I added markUnsafe: true to watches.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 under status 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 have markUnsafe: 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.
@kensipe kensipe added language/ansible Issue is related to an Ansible operator project triage/support Indicates an issue that is a support question. labels Aug 23, 2021
@kensipe kensipe added this to the Backlog milestone Aug 23, 2021
@jlhuilier-1a
Copy link

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.

@openshift-bot
Copy link

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

@openshift-ci openshift-ci bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jan 19, 2022
@agaffney
Copy link
Contributor Author

/remove-lifecycle stale

@openshift-ci openshift-ci bot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jan 19, 2022
@openshift-bot
Copy link

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

@openshift-ci openshift-ci bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Apr 19, 2022
@fabianvf
Copy link
Member

/lifecycle frozen

@openshift-ci openshift-ci bot added lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Apr 19, 2022
This was referenced Mar 23, 2023
Open
Merged
@kfox1111
Copy link

kfox1111 commented Nov 2, 2023

I think we hit this same issue.

@plnordquist plnordquist mentioned this issue Nov 6, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@fabianvf fabianvf

Labels
language/ansible Issue is related to an Ansible operator project lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. triage/support Indicates an issue that is a support question.
Projects
None yet
Milestone
Backlog
6 participants
@kensipe @agaffney @kfox1111 @openshift-bot @fabianvf @jlhuilier-1a