Modifying the options of an existing Gluster volume leads to remove-brick command

[omarkohl]

SUMMARY

When trying to update the options of an existing Gluster volume, Ansible tries to remove bricks from that volume. This fails, but should not happen anyway! The problem does NOT exist with Ansible 2.7.10 (only 2.8).

ISSUE TYPE

• Bug Report

COMPONENT NAME

glusterfs

ANSIBLE VERSION

ansible 2.8.0
  config file = /redacted/path/ansible.cfg
  configured module search path = [u'/home/someuser/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
  ansible python module location = /home/someuser/.local/lib/python2.7/site-packages/ansible
  executable location = /home/someuser/bin/ansible
  python version = 2.7.16 (default, Apr  6 2019, 01:42:57) [GCC 8.3.0]

CONFIGURATION

DEFAULT_JINJA2_EXTENSIONS(/redacted/path/ansible.cfg) = jinja2.ext.do

OS / ENVIRONMENT

STEPS TO REPRODUCE

  - name: "Set the retention-period to 120s"
    gluster_volume:
      state: present
      name: "volume1"
      options:
        { features.default-retention-period: "120" }

EXPECTED RESULTS

The option for the volume is updated and nothing else is done.

ACTUAL RESULTS

Ansible tries to remove bricks from the volume. This fails.

TASK [Set the retention-period to 120s] ****************************************
An exception occurred during task execution. To see the full traceback, use -vvv. The error was: None
fatal: [host-n1]: FAILED! => {"changed": false, "msg": "error running gluster (/usr/sbin/gluster --mode=script volume remove-brick volume1 host-n1:/gluster/brick1/glusterbrick host-n2:/gluster/brick1/glusterbrick host-n3:/gluster/brick1/glusterbrick host-n4:/gluster/brick1/glusterbrick start) command (rc=1): volume remove-brick start: failed: Removing bricks from replicate configuration is not allowed without reducing replica count explicitly.\n"}

[omarkohl]

I think it likely that it is related to #38269

[ansibot]

cc @devyanikota
click here for bot help

[devyanikota]

Hi @omarkohl
It is expected that the existing bricks in the volume are added to the playbook as well.
Remove_brick operation is triggered in the absence of the 'bricks' field, thus telling ansible that the bricks can be removed. In simple words, the exact current state of the volume is to be mentioned in the playbook, which includes the bricks in the node.
According to your requirement, in order to change the desired 'options' field for the cluster, please do mention the existing bricks in the volume to avoid this issue.
Please let us know in case you need more help. Thanks.

[omarkohl]

OK I understand... I think this behaviour is not good:

• This is a major and destructive change from version 2.7.10 to 2.8 which means that bricks could suddenly be removed from existing volumes just by performing a trivial operation such as I did
• Requiring to specify all existing bricks is a lot of overhead. I don't have easy access to that list when I am running that playbook. Why is it necessary to do this? In general in Ansible it is not necessary to specify EVERY option to change something. Things that are not part of the task are not changed per default (at least that is my understanding)

I would suggest only adding and removing bricks when the list of bricks is specified and not if it is not mentioned in the playbook.

[sac]

@omarkohl you are right. If the existing bricks are large in number it becomes a lot of overhead. And more importantly, it is error prone.