Unfortunately I fail to understand how simple changes like these introduced in the commit could have made any difference. Some explanation would be appreciated.
Sorry for reporting this 3 years after it was introduced. We were using ansible 2.9 with version of ovirt_disk provided in the package up until now and have just recently switched to ansible-core 2.16 and latest ovirt.ovirt collection. That's when we noticed the bug.
We are using Ovirt 4.5.4.
The latest working version of the ovirt_disk module was from this commit:
The effect of the bug is that playbook/task has to be run twice (without any change to the playbook itself). The first time task is run, disk is renamed. The second time task is run, disk is moved to another storage domain. This was possible to do in one go in previous versions. I have not tested changing other combinations of disk parameters.
Additionaly I have observed that disk move fails (when task is run second time) if VM is in running state. Ansible runs without issues or any errors shown but VM is shut down and left with inconsistent disk snapshot. This is possibly unrelated and caused by something else but I haven't found any solution. VM cannot be started, snapshot cannot be removed, disk stays in the original location. I can only remove the VM.
COMPONENT NAME
ovirt_disk.py
STEPS TO REPRODUCE
- hosts: ovirt-test-1
gather_facts: false
tasks:
- name: "Test disk rename and move"
ovirt.ovirt.ovirt_disk:
auth:
hostname: "{{ vm_ovirt_engine }}"
username: "{{ vm_ovirt_engine_user | default(omit) }}"
password: "{{ vm_ovirt_engine_pass | default(omit) }}"
insecure: true
# Disk ID in my example
id: "cbf97deb-9aee-4223-a842-00ba442b2da5"
# Original name is "ovirt-test-1-root", "-bla" sufix is added for test
name: "ovirt-test-1-root-bla"
# Original storage domain is "nvme-01"
storage_domain: "nvme-02"
# Disk is already attached to the machine
vm_name: "ovirt-test-1"
delegate_to: localhost
EXPECTED RESULTS
Disk rename and move should be done in one go.
ACTUAL RESULTS
Task has to be run twice. The first run renames the disk from ovirt-test-1-root to ovirt-test-1-root-bla and the second one moves the disk from nvme-01 to nvme-02.
I can provide some verbose ansible-playbook output if required.
SUMMARY
I have narrowed down the suspect to this commit that introduced the bug:
https://github.com/oVirt/ovirt-ansible-collection/commit/9ec1a91e5e198e07b049a3b39de49f6143585bc6
Unfortunately I fail to understand how simple changes like these introduced in the commit could have made any difference. Some explanation would be appreciated.
Sorry for reporting this 3 years after it was introduced. We were using ansible 2.9 with version of
ovirt_disk
provided in the package up until now and have just recently switched to ansible-core 2.16 and latestovirt.ovirt
collection. That's when we noticed the bug.We are using Ovirt 4.5.4.
The latest working version of the
ovirt_disk
module was from this commit:https://github.com/oVirt/ovirt-ansible-collection/commit/3a812ad45f7ef701413f21148133003e7157f77a
The effect of the bug is that playbook/task has to be run twice (without any change to the playbook itself). The first time task is run, disk is renamed. The second time task is run, disk is moved to another storage domain. This was possible to do in one go in previous versions. I have not tested changing other combinations of disk parameters.
Additionaly I have observed that disk move fails (when task is run second time) if VM is in running state. Ansible runs without issues or any errors shown but VM is shut down and left with inconsistent disk snapshot. This is possibly unrelated and caused by something else but I haven't found any solution. VM cannot be started, snapshot cannot be removed, disk stays in the original location. I can only remove the VM.
COMPONENT NAME
ovirt_disk.py
STEPS TO REPRODUCE
EXPECTED RESULTS
Disk rename and move should be done in one go.
ACTUAL RESULTS
Task has to be run twice. The first run renames the disk from
ovirt-test-1-root
toovirt-test-1-root-bla
and the second one moves the disk fromnvme-01
tonvme-02
.I can provide some verbose
ansible-playbook
output if required.