A template for an ansible role that configures some GNU/Linux subsystem or service. A brief description of the role goes here.

Any prerequisites that may not be covered by Ansible itself or the role should be mentioned here. This includes platform dependencies not managed by the role, hardware requirements, external collections, etc. There should be a distinction between control node requirements (like collections) and managed node requirements (like special hardware, platform provisioning).

For instance, if the role depends on some collections and has a meta/collection-requirements.yml file for installing those dependencies, and in order to manage rpm-ostree systems, it should be mentioned here that the user should run

ansible-galaxy collection install -vv -r meta/collection-requirements.yml

on the control node before using the role.

Validation is enforced by meta/argument_specs.yml.

A description of all input variables (i.e. variables that are defined in defaults/main.yml) for the role should go here as these form an API of the role. Each variable should have its own section e.g.

A string variable for the foo setting. The default value is "foo".

A boolean variable that enables or disables the bar feature. The default value is true.

An integer variable for a numeric setting. The default value is 0.

Filesystem path to the configuration file. The default value is "/etc/template.conf".

Desired state of the template subsystem. Must be one of enabled or disabled. The default value is "enabled".

A list of package names (strings). The default value is [].

A variable that accepts values of different types (e.g. a string or a list). The default value is "".

A list of service configurations. Each entry is a dictionary with the following keys:

The default value is [].

Variables that are not intended as input, like variables defined in vars/main.yml, variables that are read from other roles and/or the global scope (ie. hostvars, group vars, etc.) can be also mentioned here but keep in mind that as these are probably not part of the role API they may change during the lifetime.

Example of setting the variables:

template_foo: "oof"
template_bar: false
template_baz: 42
template_config_path: /etc/myapp/config.yml
template_state: disabled
template_packages:
  - vim
  - tmux
template_raw_value:
  - first
  - second
template_services:
  - name: httpd
    type: forking
    enabled: true
  - name: my-worker
    type: simple

This section is optional. Some roles may export variables for playbooks to use later. These are analogous to "return values" in Ansible modules. For example, if a role performs some action that will require a system reboot, but the user wants to defer the reboot, the role might set a variable like template_reboot_needed: true that the playbook can use to reboot at a more convenient time.

Example:

Default false - if true, this means a reboot is needed to apply the changes made by the role

Including an example of how to use your role (for instance, with variables passed in as parameters) is always nice for users too:

- name: Manage the template subsystem
  hosts: all
  vars:
    template_foo: "foo foo!"
    template_bar: false
    template_baz: 42
    template_state: disabled
    template_services:
      - name: httpd
        type: forking
        enabled: true
  roles:
    - linux-system-roles.template

More examples can be provided in the examples/ directory. These can be useful, especially for documentation.

See README-ostree.md

Whenever possible, please prefer MIT.

An optional section for the role authors to include contact information, or a website (HTML is not allowed).