Bug 1730311 - The embedded Ansible manageiq-automate role's 'get_attribute' task fails to return some state machine attributes
Summary: The embedded Ansible manageiq-automate role's 'get_attribute' task fails to r...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Automate
Version: 5.10.6
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: GA
: 5.11.0
Assignee: Drew Bomhof
QA Contact: Satyajit Bulage
Red Hat CloudForms Documentation
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-07-16 12:29 UTC by Peter McGowan
Modified: 2019-12-12 13:36 UTC (History)
11 users (show)

Fixed In Version: 5.11.0.23
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-12-12 13:36:50 UTC
Category: Bug
Cloudforms Team: CFME Core
Target Upstream Version:


Attachments (Terms of Use)
Playbook to reproduce the problem (808 bytes, text/plain)
2019-07-16 12:29 UTC, Peter McGowan
no flags Details
Automate domain containing state machine to reproduce problem (8.60 KB, application/zip)
2019-08-20 11:31 UTC, Peter McGowan
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:4199 None None None 2019-12-12 13:36:58 UTC

Description Peter McGowan 2019-07-16 12:29:51 UTC
Created attachment 1591032 [details]
Playbook to reproduce the problem

Description of problem:
The manager-automate role's 'get_attribute' task fails to collect the values of the ae_state_max_retries, ae_retry_server_affinity, ae_next_state or ae_state_retries root attributes if the playbook is run from a state machine. The 'get_object_attribute_names' task does however list these as valid root attributes.

The attached playbook illustrates the problem.

Version-Release number of selected component (if applicable):
5.10.6

How reproducible:
Every time


Steps to Reproduce:
1. Add the attached spreadsheet to an Ansible repository, sync the repository with a CloudForms appliance running the embeddedd Ansible role
2. Create a playbook method from the playbook. Ensure that the method has a boolean input parameter of 'manageiq_validate_certs' with value 'False', that logging is set to 'Always', and TTL to 5.
3. Call the playbook method from a state in a state machine.

Actual results:

The output from the playbook's tasks are as follows:

TASK [Get the list of root object attribute names (get_object_attribute_names)] ***
ok: [localhost]

TASK [debug] *******************************************************************
ok: [localhost] => {
    "msg": "Result:[u'ae_result', u'ae_state_max_retries', u'ae_state_started', u'ae_retry_server_affinity', u'message', u'ae_provider_category', u'user_id', u'miq_server', u'ae_state_step', u'namespace', u'ae_state', u'instance', u'object_name', u'miq_server_id', u'user', u'miq_group', u'ae_next_state', u'class', u'tenant', u'ae_state_retries', u'request', u'ae_status_state']"
}

^^^ Here we can see that the four attributes are listed as existing.

TASK [Get each of the root object's attributes (get_attribute)] ****************
ok: [localhost] => (item=ae_result)
failed: [localhost] (item=ae_state_max_retries) => {"changed": false, "item": "ae_state_max_retries", "msg": "Object root Attribute ae_state_max_retries does not exist"}
ok: [localhost] => (item=ae_state_started)
failed: [localhost] (item=ae_retry_server_affinity) => {"changed": false, "item": "ae_retry_server_affinity", "msg": "Object root Attribute ae_retry_server_affinity does not exist"}
ok: [localhost] => (item=message)
ok: [localhost] => (item=ae_provider_category)
ok: [localhost] => (item=user_id)
ok: [localhost] => (item=miq_server)
ok: [localhost] => (item=ae_state_step)
ok: [localhost] => (item=namespace)
ok: [localhost] => (item=ae_state)
ok: [localhost] => (item=instance)
ok: [localhost] => (item=object_name)
ok: [localhost] => (item=miq_server_id)
ok: [localhost] => (item=user)
ok: [localhost] => (item=miq_group)
failed: [localhost] (item=ae_next_state) => {"changed": false, "item": "ae_next_state", "msg": "Object root Attribute ae_next_state does not exist"}
ok: [localhost] => (item=class)
ok: [localhost] => (item=tenant)
failed: [localhost] (item=ae_state_retries) => {"changed": false, "item": "ae_state_retries", "msg": "Object root Attribute ae_state_retries does not exist"}
ok: [localhost] => (item=request)
ok: [localhost] => (item=ae_status_state)
...ignoring

^^^ Here we can see that all attributes except the four mentioned are returned successfully.


Expected results:
Any root attribute returned by the 'get_object_attribute_names' task should be retrievable by the 'get_attribute' task.

Additional info:

Comment 2 William Fitzgerald 2019-07-16 18:57:38 UTC
Reproduced on appliance: 10.8.99.177

Comment 3 Tina Fitzgerald 2019-07-16 19:52:10 UTC
Hi Josh,

After further investigation, this issue does not appear to be a regression.

Thanks,
Tina

Comment 5 Drew Bomhof 2019-07-19 19:59:48 UTC
PR: https://github.com/syncrou/manageiq-automate/pull/6

Comment 6 Drew Bomhof 2019-08-02 19:58:55 UTC
PR: Manageiq-content: https://github.com/ManageIQ/manageiq-content/pull/555

Comment 7 CFME Bot 2019-08-06 12:36:26 UTC
New commit detected on ManageIQ/manageiq-content/ivanchuk:

https://github.com/ManageIQ/manageiq-content/commit/959321e68f078a91315385acdd25a5d9aea5adb0
commit 959321e68f078a91315385acdd25a5d9aea5adb0
Author:     tina <tfitzger@redhat.com>
AuthorDate: Fri Aug  2 16:18:42 2019 -0400
Commit:     tina <tfitzger@redhat.com>
CommitDate: Fri Aug  2 16:18:42 2019 -0400

    Merge pull request #555 from syncrou/wrap_all_values_in_quotes

    manageiq-core.manageiq-automate Wrap all values in quotes

    (cherry picked from commit f0bf90e63d9baa19c9392995b73b99cd0223f0cd)

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

 content/ansible/roles/manageiq-core.manageiq-automate/library/manageiq_automate.py | 8 +-
 1 file changed, 7 insertions(+), 1 deletion(-)

Comment 9 Peter McGowan 2019-08-20 11:31:44 UTC
Created attachment 1606057 [details]
Automate domain containing state machine to reproduce problem

Comment 11 Drew Bomhof 2019-08-20 20:29:02 UTC
Hi Satajit,

The fix presented in https://github.com/ManageIQ/manageiq-content/pull/555 was a fix for the version of the module that ships with the appliance.

The test you ran was against the galaxy version of the module: https://galaxy.ansible.com/syncrou/manageiq-automate

This PR fixes the Galaxy version ( tested in the playbook above https://bugzilla.redhat.com/show_bug.cgi?id=1730311#c8 )

PR: https://github.com/syncrou/manageiq-automate/pull/8

Comment 12 Peter McGowan 2019-08-21 07:06:33 UTC
Hi, sorry I might have confused things. It's also failing to retrieve the ae_next_state attribute on the CFME 5.11.0.19 build with the supplied manageiq-core.manageiq-automate role.

Comment 13 Drew Bomhof 2019-08-26 18:19:06 UTC
Hi Peter,

This case where ae_next_state is not showing up in the attributes list is an edge case. 

The original request of this BZ has been resolved to my knowledge. My suggestion is to create a new BZ for this edge case and allow this BZ to be finished per the original request.

Comment 21 Tina Fitzgerald 2019-08-30 20:03:17 UTC
Please disregard comment 20, it was added in error.

Comment 22 Drew Bomhof 2019-08-30 22:05:54 UTC
PR: https://github.com/ManageIQ/manageiq-content/pull/571

Comment 23 CFME Bot 2019-09-03 17:06:15 UTC
New commit detected on ManageIQ/manageiq-content/ivanchuk:

https://github.com/ManageIQ/manageiq-content/commit/62108090eb401134c86ba9efa28795e5f710a374
commit 62108090eb401134c86ba9efa28795e5f710a374
Author:     Madhu Kanoor <mkanoor@redhat.com>
AuthorDate: Tue Sep  3 12:00:18 2019 -0400
Commit:     Madhu Kanoor <mkanoor@redhat.com>
CommitDate: Tue Sep  3 12:00:18 2019 -0400

    Merge pull request #571 from syncrou/allow_nulls_in_exist

    Allow for nulls in the exists method

    (cherry picked from commit 2c6c747a81a15cb7b9667644dcb4abff91d7a7c1)

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

 content/ansible/roles/manageiq-core.manageiq-automate/library/manageiq_automate.py | 15 +-
 1 file changed, 7 insertions(+), 8 deletions(-)

Comment 25 Satyajit Bulage 2019-09-06 14:05:04 UTC
As per comment 24 I don't see any attribute is missing.

Verified Version: 5.11.0.23.20190904213640_d113674

Comment 27 errata-xmlrpc 2019-12-12 13:36:50 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:4199


Note You need to log in before you can comment on or make changes to this bug.