Skip to content

Latest commit

 

History

History
133 lines (107 loc) · 7.51 KB

README.md

File metadata and controls

133 lines (107 loc) · 7.51 KB
Raw

Ansible Role jm1.cloudy.storage

This role helps with managing partitions, encrypted (LUKS) devices, LVM volume groups, LVM volumes, filesystems and mountpoints from Ansible variables. Role variable storage_config defines a list of tasks which will be run by this role. Each task calls an Ansible module similar to tasks in roles or playbooks except that only few keywords such as when are supported. For example, to create an ext4 primary partition on device /dev/sdb, define variable storage_config in group_vars or host_vars as such:

storage_config:
- # Create ext4 primary partition on device /dev/sdb
  community.general.parted:
    device: /dev/sdb
    fs_type: ext4
    number: 1
    state: present

When this role is executed, it will run all tasks listed in storage_config one after another. When storage_config includes meta: flush_handlers and storage_reboot evaluates to true, then this role will reboot the system immediately and continue with remaining tasks in storage_config once the host has come up again. Once all tasks have finished, if anything has changed and storage_reboot evaluates to true, then the system will be rebooted automatically.

Tested OS images

Available on Ansible Galaxy in Collection jm1.cloudy.

Requirements

This role uses module(s) from collection jm1.ansible. To install this collection you may follow the steps described in README.md using the provided requirements.yml.

Variables

Name Default value Required Description
storage_config [] false List of tasks to run 1 2 3
storage_reboot false false Whether the system should be rebooted on meta: flush_handlers or after all changes have been applied

Dependencies

None.

Example Playbook

- hosts: all
  become: true
  vars:
    # Variables are listed here for convenience and illustration.
    # In a production setup, variables would be defined e.g. in
    # group_vars and/or host_vars of an Ansible inventory.
    # Ref.:
    # https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html
    # https://docs.ansible.com/ansible/latest/user_guide/intro_inventory.html
    storage_config:
    - # Create ext4 primary partition on device /dev/sdb
      community.general.parted:
        device: /dev/sdb
        fs_type: ext4
        number: 1
        state: present

    # reboot system after changes have been applied
    storage_reboot: true
  roles:
  - name: Manage partitions, encrypted (LUKS) devices, LVM volume groups, LVM volumes, filesystems and mountpoints
    role: jm1.cloudy.storage
    tags: ["jm1.cloudy.storage"]

For instructions on how to run Ansible playbooks have look at Ansible's Getting Started Guide.

License

GNU General Public License v3.0 or later

See LICENSE.md to see the full text.

Author

Jakob Meng @jm1 (github, galaxy, web)

Footnotes

  1. Useful Ansible modules in this context could be crypttab, mount, luks_device, lvg, lvol and parted. ↩

  2. Tasks will be executed with jm1.ansible.execute_module which supports keyword when only. ↩

  3. Tasks will be executed with jm1.ansible.execute_module which supports modules and action plugins only. Some Ansible modules such as ansible.builtin.meta and ansible.builtin.{include,import}_{playbook,role,tasks} are core features of Ansible, in fact not implemented as modules and thus cannot be called from jm1.ansible.execute_module. Doing so causes Ansible to raise errors such as MODULE FAILURE\nSee stdout/stderr for the exact error. (Only exception is meta: flush_handlers which is fully supported). In addition, Ansible does not support free-form parameters for arbitrary modules, so for example, change from - debug: msg="" to - debug: { msg: "" }. ↩