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
Ansible operator: integer values of keys in objects in custom resources are strings in the ansible role #1701
Comments
I was able to reproduce with just plain Ansible (without the operator-sdk). Notice though how I was still able to add to {{ my_object.object_int }} and treat it like an integer, even though it looks like a string in the debug output. ansible --version:
playbook.yaml:
roles/test-role/defaults/main.yaml:
roles/test-role/tasks/main.yaml:
ansible-playbook playbook.yaml:
|
Found this issue here, which does a good job of explaining why those are strings in the debug output ansible/ansible#30366. Basically, it's a limitation of jinja2 in which the values can only be returned as strings (although it's interesting that the top_level_int actually looks like an integer) |
This is a problem of old versions of Jinja2 and Ansible. Later versions of Jinja2 along with Ansible configuration now allow all this to work as expected and have integers be returned. What's interesting here is it works correctly for the top level key but not for keys that part of objects. |
I have been able to patch this by updating the operator image Jinja2 to latest version ( Can we get jinja2 updated in the base image as well as setting jinja_native2 = true by default ? I think most custom resource types are going to have specifications that have integers with the intention that they are used as integers in the Ansible roles. |
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 |
Stale issues rot after 30d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle rotten |
Hi @gearoidibm, The ansible and its deps were updated. Are you able to face the same issue with a project upgraded and/or created using the SDK 0.12? |
Rotten issues close after 30d of inactivity. Reopen the issue by commenting /close |
@openshift-bot: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/remove-lifecycle rotten |
/reopen |
@StevenMercurio: You can't reopen an issue/PR unless you authored it or you are a collaborator. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
@StevenMercurio it was re-opened as you requested. |
There seems to be no way I can figure out to stop an int that I assign to a var from being turned into a string when I use the variable to try and put the data where I need it. :( |
Also raised in #2609 , and in ansible ansible/ansible#40185 , and discussed on slack https://kubernetes.slack.com/archives/CAW0GV7A5/p1582893529107700 Basically the issue here is that when you have an inline template, jinja templated fields always end up as strings (because they are wrapped in quotes and then yaml loaded). In order to get these fields to be loaded as non-strings, you need to load the template from a file, where the Unfortunately I don't think there is a possible resolution on our end, though extra docs would make sense. |
I found a solution that seems to work and it doesn't require the If instead of
you do
you can omit the " in the jinja template and the value is not converted to string! |
Yeah I just hit this one hard until I saw this. @fabianvf said:
Can we get this re-opened for updating the docs? Or does that need to be a separate issue? |
Bug Report
What did you do?
Created an integer value of a key in an object in the custom resource and refer to it in the ansible task.
What did you expect to see?
The variable is an integer in the task so that it can be used as an integer in ansible modules.
For example as the number of replicas for a pod.
What did you see instead? Under which circumstances?
The variable is a sting in the task and causes ansible modules that require an integer to fail.
For example using the
K8s
module.Filtering the value using
| int
also results in a string value.Environment
operator-sdk version: 0.9.0
go version:
N/A
Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.0", GitCommit:"e8462b5b5dc2584fdcd18e6bcfe9f1e4d970a529", GitTreeState:"clean", BuildDate:"2019-06-20T04:49:16Z", GoVersion:"go1.12.6", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.0", GitCommit:"e8462b5b5dc2584fdcd18e6bcfe9f1e4d970a529", GitTreeState:"clean", BuildDate:"2019-06-19T16:32:14Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"}
minikube
ansible
Possible Solution
Additional context
top level integer variables are correctly available as integers in the task.
Example CRD, CR, and role
CR
Role
Output from ansible container log:
NOTE top_level_int is an
int
,there's no""
s, where as my_object.object_int is a string, it's surrounded by""
s.The text was updated successfully, but these errors were encountered: