Bug 1625047

Matt,

Is there a reproducer environment?

Thanks

Billy

(In reply to William Fitzgerald from comment #3)
> Matt,
> 
> Is there a reproducer environment?
> 
> Thanks
> 
> Billy

Hi Billy

I have sent you environment information and access details directly

Thanks,
Matt

Matt,

I am seeing the same results on a 5.9.4.5 appliance.  

Billy

https://github.com/ManageIQ/manageiq-automation_engine/pull/222

New commit detected on ManageIQ/manageiq-automation_engine/master:

https://github.com/ManageIQ/manageiq-automation_engine/commit/4eb6a937ed1bda6e6b278fb027292283b847be5f
commit 4eb6a937ed1bda6e6b278fb027292283b847be5f
Author:     Madhu Kanoor <mkanoor>
AuthorDate: Thu Sep  6 11:49:55 2018 -0400
Commit:     Madhu Kanoor <mkanoor>
CommitDate: Thu Sep  6 11:49:55 2018 -0400

    Clear stale data from ae_state_data and ae_state_previous

    https://bugzilla.redhat.com/show_bug.cgi?id=1625047

    The ansible playbook was one of the first times we have cared
    about what is the ae_state_data, the playbook method clears out
    the key ae_state_data fields regarding the automate_workspace and
    the taskid that was used to track the playbook on a completion of the
    playbook (either with 'ok' or 'retry'). Since the stale state data
    wasn't being cleared the playbook wasn't getting successfully launched
    on a retry and would bail looking for stale automate workspaces.

 lib/miq_automation_engine/engine/miq_ae_engine.rb | 2 +
 spec/engine/miq_ae_state_machine_retry_spec.rb | 13 +
 2 files changed, 15 insertions(+)

Satyajit,

In case Matt doesn't send you his playbook, here is the one I tested with.

https://github.com/billfitzgerald0120/ansible_playbooks/blob/master/set_retry_60_seconds.yml

Billy

Hi Satyajit

I have uploaded the playbook I used for testing to https://github.com/mattparko/manageiq-playbooks/blob/master/retry.yml

It uses the same manageiq-automate role and set_retry task as Billy's example. The only difference is that it only attempts to set the state result to retry for the first 3 runs, after which it exits successfully with the normal "ok" result.

This could be helpful for testing both success/failure scenarios, by simply adjusting max number of retries in the state machine.

Thanks,
Matt

Playbook has an error: 

In evm.log:


ERROR! the role 'syncrou.manageiq-automate' was not found in /var/lib/awx/projects/_7__testing_bz/roles:/etc/ansible/roles:/usr/share/ansible/roles:/var/lib/awx/projects/_7__testing_bz

The error appears to have been in '/var/lib/awx/projects/_7__testing_bz/retry.yml': line 14, column 7, but may
be elsewhere in the file depending on the exact syntax problem.

The offending line appears to be:

  roles:
    - syncrou.manageiq-automate
      ^ here


Billy

Satyajit,

You could try one of my retry playbooks.

I like playbook set_retry_with_input.yml in 

https://github.com/billfitzgerald0120/ansible_playbooks.



1. Add this to input Parameters (Extra vars):

manageiq_validate_certs as false

2. I recommend setting logging output to "Always" 
3. I recommend setting Verbosity to 3

You will get more information in the evm.log

Adding a screenshot

Hope this helps ...

Billy

Created attachment 1490691 [details]
Ansible logging and certs

With the Help of William followed
Verification Steps:

1. Enable Embedded Ansible
2. Add repository - https://github.com/billfitzgerald0120/ansible_playbooks
3. Import Ansible_StateMachine_Set_Retry
4. Enable domain
5. Verify the Playbook method (set_retry_4_times) or use your own playbook
6. Add a dummy dialog
7. Add a catalog
8. Add a new Catalog item (Generic Type)
9. Order service
10. Check automation.log to make sure the playbook retried 3 times and then ended OK.


Verified Version: 5.10.0.31.20190108221820_a0968c8