Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LVM size is not supporting 100% option. #11

Open
tabowling opened this issue Nov 24, 2018 · 4 comments
Open

LVM size is not supporting 100% option. #11

tabowling opened this issue Nov 24, 2018 · 4 comments

Comments

@tabowling
Copy link
Contributor

LVM size is not supporting 100% option. I tried multiple syntax combinations: "100%", '100%' but both failed.

TASK [linux-system-roles.storage : parse the specified size] **********************************************************************************************************************
fatal: [rhel7]: FAILED! => {"changed": false, "module_stderr": "Shared connection to rhel7 closed.\r\n", "module_stdout": "Traceback (most recent call last):\r\n  File \"/root/.ansible/tmp/ansible-tmp-1543067239.8836384-269315629014179/AnsiballZ_bsize.py\", line 113, in <module>\r\n    _ansiballz_main()\r\n  File \"/root/.ansible/tmp/ansible-tmp-1543067239.8836384-269315629014179/AnsiballZ_bsize.py\", line 105, in _ansiballz_main\r\n    invoke_module(zipped_mod, temp_path, ANSIBALLZ_PARAMS)\r\n  File \"/root/.ansible/tmp/ansible-tmp-1543067239.8836384-269315629014179/AnsiballZ_bsize.py\", line 48, in invoke_module\r\n    imp.load_module('__main__', mod, module, MOD_DESC)\r\n  File \"/tmp/ansible_bsize_payload_fk39wL/__main__.py\", line 89, in <module>\r\n  File \"/tmp/ansible_bsize_payload_fk39wL/__main__.py\", line 86, in main\r\n  File \"/tmp/ansible_bsize_payload_fk39wL/__main__.py\", line 71, in run_module\r\n  File \"/tmp/ansible_bsize_payload_fk39wL/ansible_bsize_payload.zip/ansible/module_utils/size.py\", line 22, in __init__\r\n  File \"/tmp/ansible_bsize_payload_fk39wL/ansible_bsize_payload.zip/ansible/module_utils/size.py\", line 88, in _parse_units\r\nValueError: Unable to identify unit '%'\r\n", "msg": "MODULE FAILURE\nSee stdout/stderr for the exact error", "rc": 1}

Playbook used was:

- hosts: all
  become: yes
  become_method: sudo
  become_user: root

  vars:
    use_partitions: false
  tasks:
    - name: Configure Composer Storage
      include_role:
        name: linux-system-roles.storage
      vars:
        storage_pools:
          - name: composer
            disks: ['vdb']
            # type: lvm
            state: present
            volumes:
              - name: composer
                size: 20G
                # type: lvm
                # fs_type: xfs
                fs_label: "composer"
                mount_point: '/var/lib/lorax/composer'

@dwlehman
Copy link
Collaborator

@pcahyna had concerns about this and idempotence. I still think there is more to discuss on that topic. With storage, the ability to achieve idempotence will depend on the conditions in the system whether or not we support percentage-based sizes: one example is the size and/or number of disks, which could prevent creation of a file system of the desired size. It is my opinion that we can handle percentage-based sizes correctly, but it will take more work to ensure that subsequent runs will do the right thing.

@pcahyna
Copy link
Member

pcahyna commented Nov 26, 2018

Is it meant as the percentage of the total space or of the free space?

@dwlehman
Copy link
Collaborator

I think if we limit to percentage of pool size it will not interfere with idempotence.

FWIW I also have a change to automatically cap sizes as needed to fit in pools, which would allow you to make a pool w/ a single 10GiB disk and then create a volume w/ size 10GiB instead of having to try to account for the metadata yourself. It's currently mixed in with the other changes in #39 but I will split that piece out since it's distinct from the rest.

@pcahyna
Copy link
Member

pcahyna commented Aug 26, 2019

I think if we limit to percentage of pool size it will not interfere with idempotence.

I think so as well.

FWIW I also have a change to automatically cap sizes as needed to fit in pools, which would allow you to make a pool w/ a single 10GiB disk and then create a volume w/ size 10GiB instead of having to try to account for the metadata yourself. It's currently mixed in with the other changes in #39 but I will split that piece out since it's distinct from the rest.

I am not sure whether it is the right thing to do - shouldn't one rather use "100%" in this case? I am a bit afraid of silently doing something a bit different than the user requested.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants