How to set the output of Ansible Playbook values to the Dynamic drop down?

I have created a new domain, namespace, class, Instances and 2 methods.
Method 1 : method type - Playbook

  • hosts: localhost
    connection: local
    gather_facts: false


    • manageiq_validate_certs: false


    • syncrou.manageiq-automate


    • name: task1
      xyz module:
      register: output

    • name:
      ansi_output: “{{ output }}”

    • name: print info
      var: item
      with_items: “{{ output | json_query(‘output[*].name’) }}”

    • name: “Set an attribute”
      workspace: “{{ workspace }}”
      object: “root”
      attribute: “ansi_output”
      value: “{{ output }}”
      register: workspace

    • name: “Save the job ID back into $evm.root”
      workspace: “{{ workspace }}”
      object: “root”
      attribute: “tower_job_id”
      value: “{{ tower_job_id }}”

Method 2 : method type - inline

Trying to call ansible playbook method

$evm.instantiate(‘domain/namespace/class/Instance Name’)

JOB_CLASS = ‘ManageIQ_Providers_EmbeddedAnsible_AutomationManager_Job’.freeze
tower_job_id = $evm.root[‘tower_job_id’].to_s
if tower_job_id.blank?
raise “No Tower Job ID returned, cannot get output”
job = $evm.vmdb(JOB_CLASS).where([“ems_ref = ?”, tower_job_id]).first
$evm.log(:info, “Output from previous Ansible playbook: \n#{job.stdout}”)

Setting values to dynamic drop down

dialog_field = $evm.object
dialog_field[“data_type”] = “string”
dialog_field[“value”] = $evm.get_state_var(“ansible_stats_ansi_output”)

I am getting Script error in the dynamic dropdown field

Need help to troubleshoot and resolve the error.

Please provide your suggestions.

State vars are intended to be used within state machines, they won’t save values between an instantiated instance and its caller.

Check the log files. Is the Ansible playbook method running? Make sure you log all output in the method definition, then it should go to evm.log.
Is the $evm.log(:info, “Output from previous Ansible playbook: \n#{job.stdout}”) line printing anything from the Ruby method?

You could try implementing this as a 2-state state machine, where the first state calls your playbook method, and the second state calls your Ruby method. Your Ruby method won’t need to call $evm.instantiate as the playbook method has already been run. Also the role has been updated and included in the appliance now, its called manageiq-core.manageiq-automate (see the blog series on using the built-in roles, starting here)

A dynamic method that populates a dynamic drop-down needs to return a hash or array in its dialog_field[“value”]. Is your dialog element type a drop-down, or a text (or text area) box? You probably want the latter if you’re displaying a string.

Ultimately though I think running a playbook method as part of dynamic dialog’s instance would be quite slow, and not great user experience? My advice would be to stick to pure Ruby for this.

Hope this helps,

1 Like

First of all Thank you for your valuable reply @pemcg

Actually I am new to this, I am learning one by one with help of this following links:

Those are very useful.

I checked in evm.log: Ansible playbook method is not triggered due to some timeout error, while checking this I found that some lines are repeatedly printing in evm.log.

Need your help.

Below are the lines:
/var/www/miq/vmdb/app/models/metric/ci_mixin/capture.rb:195:in just_perf_capture' /var/www/miq/vmdb/app/models/metric/ci_mixin/capture.rb:141:in perf_capture’
/var/www/miq/vmdb/app/models/metric/ci_mixin/capture.rb:117:in perf_capture_realtime' /var/www/miq/vmdb/app/models/miq_queue.rb:479:in block in dispatch_method’
/usr/share/ruby/timeout.rb:93:in block in timeout' /usr/share/ruby/timeout.rb:33:in block in catch’
/usr/share/ruby/timeout.rb:33:in catch' /usr/share/ruby/timeout.rb:33:in catch’
/usr/share/ruby/timeout.rb:108:in timeout' /var/www/miq/vmdb/app/models/miq_queue.rb:477:in dispatch_method’
/var/www/miq/vmdb/app/models/miq_queue.rb:454:in block in deliver' /var/www/miq/vmdb/app/models/user.rb:290:in with_user_group’
/var/www/miq/vmdb/app/models/miq_queue.rb:454:in deliver' /var/www/miq/vmdb/app/models/miq_queue_worker_base/runner.rb:104:in deliver_queue_message’
/var/www/miq/vmdb/app/models/miq_queue_worker_base/runner.rb:137:in deliver_message' /var/www/miq/vmdb/app/models/miq_queue_worker_base/runner.rb:155:in block in do_work’
/var/www/miq/vmdb/app/models/miq_queue_worker_base/runner.rb:149:in loop' /var/www/miq/vmdb/app/models/miq_queue_worker_base/runner.rb:149:in do_work’
/var/www/miq/vmdb/app/models/miq_worker/runner.rb:329:in block in do_work_loop' /var/www/miq/vmdb/app/models/miq_worker/runner.rb:326:in loop’
/var/www/miq/vmdb/app/models/miq_worker/runner.rb:326:in do_work_loop' /var/www/miq/vmdb/app/models/miq_worker/runner.rb:153:in run’
/var/www/miq/vmdb/app/models/miq_worker/runner.rb:127:in start' /var/www/miq/vmdb/app/models/miq_worker/runner.rb:22:in start_worker’
/var/www/miq/vmdb/app/models/miq_worker.rb:398:in block in start_runner_via_fork' /opt/rh/cfme-gemset/gems/nakayoshi_fork-0.0.4/lib/nakayoshi_fork.rb:23:in fork’
/opt/rh/cfme-gemset/gems/nakayoshi_fork-0.0.4/lib/nakayoshi_fork.rb:23:in fork' /var/www/miq/vmdb/app/models/miq_worker.rb:396:in start_runner_via_fork’
/var/www/miq/vmdb/app/models/miq_worker.rb:386:in start_runner' /var/www/miq/vmdb/app/models/miq_worker.rb:437:in start’
/var/www/miq/vmdb/app/models/miq_worker.rb:269:in start_worker' /var/www/miq/vmdb/app/models/miq_worker.rb:147:in block in sync_workers’
/var/www/miq/vmdb/app/models/miq_worker.rb:147:in times' /var/www/miq/vmdb/app/models/miq_worker.rb:147:in sync_workers’
/var/www/miq/vmdb/app/models/miq_server/worker_management/monitor.rb:54:in block in sync_workers' /var/www/miq/vmdb/app/models/miq_server/worker_management/monitor.rb:50:in each’
/var/www/miq/vmdb/app/models/miq_server/worker_management/monitor.rb:50:in sync_workers' /var/www/miq/vmdb/app/models/miq_server/worker_management/monitor.rb:22:in monitor_workers’
/var/www/miq/vmdb/app/models/miq_server.rb:346:in `block in monitor’

As you suggested, I will try to implement this as a 2-state state machine but I don’t know how to do that (Please share any link to help on this).

Yes, as you told running a playbook method as part of dynamic dialog’s instance is quite slow. So, I will try to use Pure Ruby.

Thank you pemcg.

That’s actually quite an old version of the automate gitbook. The most recent version is here:

and the the addendum continues on from that. State machines are covered in chapter 13 of ‘Mastering…’.

I think that those errors that you’ve found have nothing to do with the non-running of the playbook.


1 Like

Thank you @pemcg

I will see chapter 13 and will learn about State machines, then will try to apply that in my flow.

Thirumurugan C

Hi @pemcg

I have created 2-state State Machine, where the first state calls playbook method, and the second state calls Ruby method.

job timed out after 26.124899328 seconds of inactivity. Inactivity threshold [0 seconds]

While running I am getting below error in log:

ERROR – : State= running on_entry raised exception: <job timed out after 26.124899328 seconds of inactivity. Inactivity threshold [0 seconds]>
WARN – : Error in State=[CustomState]

Need your help.


What did you set as the ‘Max TTL (mins)’ in the playbook method definition? I’d suggest making this about 5 minutes for testing.

1 Like

Hi @pemcg

Thank you. Yes, I gave ‘Max TTL (mins)’ = 5 mins in the playbook method definition. Now both the states ran successfully.

For testing purpose, in service dialog i have kept a dynamic text box.

When i order a Service catalog, Service dialog form loaded quite fast without updating the value to the dynamic textbox.

Able to see the output in the log
INFO – : Output from previous Ansible playbook: testing

but unfortunately unable to update that in textbox.

Below is the inline method script:
dialog_field = $evm.object
dialog_field[“data_type”] = “string”
dialog_field[“value”] = $evm.get_state_var(‘ansible_stats_ansi_output’)
$evm.log(:info, “Output from previous Ansible playbook: #{$evm.get_state_var(‘ansible_stats_ansi_output’)}”)

Help me to troubleshoot this.

Hi, sorry, my bad on this, it seems you can’t run a state machine from a dialog because here is no provision for the automatic retry that the playbook state goes into.

I think you need to use Ruby to populate your dynamic dialogs.


1 Like

Thank you @pemcg

I will try to use pure ruby method.