# SPDX-License-Identifier: MIT
---
# List of pod specifications using Kubernetes YAML format
podman_kube_specs: []

# If this is true, the role will automatically create the host directories
# specified in volume or mount.
podman_create_host_directories: false

# If you want the role to create and manage the host directories for
# bind mounts, specify the parameters as path: {arguments for file: module}
# To specify the default file properties, use DEFAULT for the name of the
# directory.
podman_host_directories: {}

# If you want the role to manage the firewall on the ports you are
# using, specify the arguments to pass to the firewall system role.
# For example, if you want the podman role to open tcp port 8080
# in the default zone:
# podman_firewall:
#   - port: 8080/tcp
# to open a range of ports:
# podman_firewall:
#   - port: 8080-8082/tcp
podman_firewall: []

# If you want the role to manage the selinux policy on the ports
# you are using, specify the arguments to pass to the selinux
# system role.  For example, if you want to allow the opening
# of port 8080 as an http port:
# podman_selinux_ports:
#   - ports: 8080
#     setype: http_port_t
podman_selinux_ports: []

# The default user to run as - can be set per container to override
# this in the podman_kube_specs list element using "run_as_user: username"
podman_run_as_user: root

# The default group to run as - can be set per container to override
# this in the podman_kube_specs list element using "run_as_group: name"
# The default 'null' means determine the group from the user information
# from the managed host
podman_run_as_group:

# By default, the scope will be user for rootless containers, and
# system for root containers.  You can override this for all containers
# by setting podman_systemd_unit_scope.  You can also specify the scope
# per container to override this and the default setting, by using
# "system_unit_scope: value" in the podman_kube_specs list element.
podman_systemd_unit_scope:

# containers.conf(5) settings, these will be provided in a drop-in
# TOML file at __podman_containers_conf_system
podman_containers_conf: {}

# containers-registries.conf(5) settings, these will be provided in a drop-in
# If running as root, the configuration file will be created in
# __podman_registries_conf_system or __podman_registries_conf_user
# paths, respectively, depending on execution mode selected
podman_registries_conf: {}

# containers-storage.conf(5) settings
# If running as root, the configuration file will be created in
# __podman_storage_conf_system or __podman_storage_conf_user
# paths, respectively, depending on execution mode selected
podman_storage_conf: {}

# containers-policy.json(5) settings
# If running as root, the configuration file will be created in
# __podman_policy_json_system or __podman_policy_json_user
# paths, respectively, depending on execution mode selected
podman_policy_json: {}

# List of Quadlet specifications
# https://man.archlinux.org/man/extra/podman/quadlet.5.en
# A quadlet spec is uniquely identified by a name and a type,
# where type is one of the types of units like container,
# kube, network, volume, etc.
podman_quadlet_specs: []

# List of podman secret specs.
# Each item in the list is a dict in the same format
# as accepted by containers.podman.podman_secret
podman_secrets: []

# Activate all systemd units once created
# You can also do this on a per-unit basis by using
# activate_systemd_units in the spec for each unit
# For example, if you are deploying several specs,
# and you only want the last one in the list to activate
# which will trigger the others to activate via dependencies,
# then set `activate_systemd_unit: false` for each one
# except the last one uses `activate_systemd_unit: true`
podman_activate_systemd_unit: true

# Ensure images used are present
# Look at the specs, and pull images that are specified there
# You can also do this on a per-spec basis using pull_images
podman_pull_image: true

# Continue if the image pull fails
# If pulling the image fails, do not fail the role - continue
# running the role.
# You can do this on a per-spec basis using continue_if_pull_fails
podman_continue_if_pull_fails: false

# Retry failed pulls
# If true, if a pull attempt fails, it will be retried according
# to the default Ansible `until` behavior.
podman_pull_retry: false

# username to use to authenticate to the registry
# override by specifying registry_username on a per-spec basis
podman_registry_username: "{{ container_image_user | d('') }}"

# password to use to authenticate to the registry
# override by specifying registry_password on a per-spec basis
podman_registry_password: "{{ container_image_password | d('') }}"

# List of files containing registry credentials
# If not using the default containers-auth.json, you may need to
# also provide an entry for "credential-helpers" in the registries.conf
# For more information, see "man containers-auth.json" and
# "man containers-registries.conf"
podman_credential_files: []

# This variable is a `list` of `dict` elements that allows you to manage TLS
# certificates and keys used to connect to registries
podman_registry_certificates: []

# Can set to true or false to control if pulling images from
# registries will validate the TLS certs.
# The default null means to use whatever is the default used
# by the containers.podman.podman_image module
# You can override this on a per-spec basis using validate_certs
podman_validate_certs:

# Prune images when removing quadlets/kube specs -
# this will remove all unused/unreferenced images
podman_prune_images: false

# var to manage reboots for transactional update systems
podman_transactional_update_reboot_ok:

# var to set to use new TOML formatter
podman_use_new_toml_formatter: false
