Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
After having fixed the problems that were preventing the VDO Ansible module from interacting with VDO (bug 1536214 and bug 1536522), I found that the module was running in a way that would always return a "changed" value of "True" if the state of deduplication or compression were changed, regardless of whether the operation actually did run. This is incorrect; if the playbook tries to change something, and fails in a way that results in no change, it should show a "changed" return status for that task.
Version-Release number of selected component (if applicable):
vdo-6.1.0.114-14.x86_64
How reproducible:
This would only appear if the "vdo enableCompression", "vdo disableCompression", "vdo enableDeduplication", or "vdo disableDeduplication" call were to fail
Steps to Reproduce:
1. Install the vdo.py ansible module to the Ansible ".../modules/system" subdirectory of the system to run VDO, and a control system.
2. Copy one of the example playbooks from the /usr/share/doc/vdo/examples/ansible directory of the system with VDO to the control system, and create a playbook that uses a local username, acts on a block device existing on the system, and has various other parameters.
Recommended sequence: use /usr/share/doc/vdo/examples/ansible/test_vdocreate.yml as a base for a creation playbook, /usr/share/doc/vdo/examples/ansible/test_vdoremove.yml as a base for a removal playbook.
3. Create a copy of the modified "test_vdocreate.yml", with the following additional lines:
- test_vdocreate_yescompress.yml: "compression: enabled"
- test_vdocreate_nocompress.yml: "compression: disabled"
- test_vdocreate_yesdedupe.yml: "deduplication: enabled"
- test_vdocreate_nodedupe.yml: "deduplication: disabled"
4. On the control system, after passwordless ssh has been established, execute "ansible-playbook <playbook_filename.yml>". Run the "test_vdocreate.yml" equivalent script to create the VDO volume, and then run "test_vdocreate_nodedupe.yml" to disable deduplication.
Actual results:
The "changed" status for a compression or deduplication status change will be "True", regardless of outcome.
Expected results:
The "changed" status for a compression or deduplication status change will be "True" only if the return code from that call is 0 (success).
Additional info:
This issue is something that was found while working to resolve BZ 1536214, but would not be seen in a released version. Since this wouldn't be reproducible in the released version, this BZ will be closed as INSUFFICIENT_DATA.
The fix for this issue will be in BZ 1536214.