I’m trying to use command like that: hammer job-invocation create --job-template "Ansible Roles - Ansible Upgrade Packages" --search-query it-is-myserver --tags "snapshot_dev" --tags-flag include --effective-user root --organization-id 1
It seems like formatting of --tags is wrong and is ignored when I’m trying to use the above command. It works completely fine when I’m using “tags” field in Foreman web UI.
Expected outcome:
Tags should work the same way in hammer as in Foreman web UI.
Foreman and Proxy versions:
Foreman
Version: 3.1.0-rc2
Proxy
Version: 3.1.0-rc2
Foreman and Proxy plugin versions:
Plugins:
Name: foreman-tasks
Version: 5.2.0
Name: foreman_ansible
Version: 6.4.1
Name: foreman_default_hostgroup
Version: 6.0.0
Name: foreman_discovery
Version: 19.0.1
Name: foreman_hooks
Version: 0.3.17
Name: foreman_kubevirt
Version: 0.1.9
Name: foreman_openscap
Version: 5.1.0
Name: foreman_puppet
Version: 2.0.0
Name: foreman_remote_execution
Version: 4.8.0
Name: foreman_setup
Version: 7.0.0
Name: foreman_snapshot_management
Version: 2.0.1
Name: foreman_templates
Version: 9.1.0
Name: katello
Version: 4.3.0.rc1
Distribution and version:
CentOS Linux release 7.9.2009 (Core)
Other relevant data:
I took the output from the Dynaflow Console.
This one is when I’m using Foreman web UI, and it is working completely fine:
proxy_operation_name: ansible-runner
tags: snapshot_dev
tags_flag: include
ansible_inventory:
all:
hosts:
This one is when I’m trying to use hammer command from the beginning of my post:
---
proxy_operation_name: ansible-runner
tags: '["snapshot_dev"]'
tags_flag: include
ansible_inventory:
all:
hosts:
As you can see, there is difference in this output: tags: snapshot_dev
and tags: '["snapshot_dev"]'
It seems like there is an issue on the API side (the tags extension comes from foreman_ansible [1] plugin), which whether incorrectly describes the params or incorrectly translates/accepts them OR in hammer which relies on the API docs to send values for the params, but in that case I’d fix the API/docs…
@ezr-ondrej, I guess you’re the one more familiar with the code of that plugin now I’ve found where the docs are coming from [2] and now I’m curious if it’s right. The description says it’s should be a comma separated list, which implies a simple string, but the type there is array…
It seems that smart-proxy part is expecting an array or string.
But we first save the inputs into database through model InvocationProviderInputValue [1] and that saves the Array value as string. So once retrieved [2] it is already retrieved as string value. This causes tags = '[tag]' and --tags '[tag]' to be passed to the ansible runner at [3].
So I see two options for fixing this:
Do not allow arrays as inputs, and just expect comma separated strings directly.
simpliest option as we need to change only the type in docs from Array to string
We allow the tags to be array and fix the InvocationProviderInputValue model to allow passing arrays as well as strings.
Better option IMHO as it will fix it for any future inputs as well, but it will be harder to implement as we have to serialize the value column which will need migration for the current values.
@obol89 still willing to file a PR for any of these options, or your own if you figure third?
Thank you for your answers.
Thank you to @ofedoren as well.
Sure, I will prepare PR for this one. I’m happy to help with developing this tool. I will look at this tomorrow and decide which option will be more convenient (!= easier).
I’ve found where the docs are coming from [2] and now I’m curious if it’s right. The description says it’s should be a comma separated list, which implies a simple string, but the type there is array…