Hammer job-invocation tags have wrong formatting


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:

Version: 3.1.0-rc2

Version: 3.1.0-rc2

Foreman and Proxy plugin versions:


  1. Name: foreman-tasks
    Version: 5.2.0
  2. Name: foreman_ansible
    Version: 6.4.1
  3. Name: foreman_default_hostgroup
    Version: 6.0.0
  4. Name: foreman_discovery
    Version: 19.0.1
  5. Name: foreman_hooks
    Version: 0.3.17
  6. Name: foreman_kubevirt
    Version: 0.1.9
  7. Name: foreman_openscap
    Version: 5.1.0
  8. Name: foreman_puppet
    Version: 2.0.0
  9. Name: foreman_remote_execution
    Version: 4.8.0
  10. Name: foreman_setup
    Version: 7.0.0
  11. Name: foreman_snapshot_management
    Version: 2.0.1
  12. Name: foreman_templates
    Version: 9.1.0
  13. 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.

  1. 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
  1. 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

As you can see, there is difference in this output:
tags: snapshot_dev
tags: '["snapshot_dev"]'

If someone is able to indicate where this part of the code exists, I’m keen to prepare a pull request. I just couldn’t find where to repair it.

Hi @obol89,

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…

[1] - GitHub - theforeman/foreman_ansible: Ansible integration in Foreman
[2] - foreman_ansible/ansible_provider.rb at 1a5c3dc47839e279d1c2aac1f70b913646104150 · theforeman/foreman_ansible · GitHub

@ezr-ondrej, I guess you’re the one more familiar with the code of that plugin now :slight_smile: 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:

  1. 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
  2. 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? :slight_smile:

I have filed a Redmine ticket for this.

[1] - foreman_remote_execution/invocation_provider_input_value.rb at e2996836c24c21f6cf0813affa0dde0518d47202 · theforeman/foreman_remote_execution · GitHub
[2] - foreman_ansible/ansible_provider.rb at 1a5c3dc47839e279d1c2aac1f70b913646104150 · theforeman/foreman_ansible · GitHub
[3] - smart_proxy_ansible/ansible_runner.rb at 2b3bd40b87601760dfdaad062db0bc9b601bccd7 · theforeman/smart_proxy_ansible · GitHub

1 Like

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).