sap.sap_operations.pcs_config_checks role – Run pcs cluster checks
Note
This role is part of the sap.sap_operations collection.
It is not included in ansible-core
.
To check whether it is installed, run ansible-galaxy collection list
.
To install it use: ansible-galaxy collection install sap.sap_operations
.
To use it in a playbook, specify: sap.sap_operations.pcs_config_checks
.
Entry point main
– Run pcs cluster checks
Synopsis
Parameters
Parameter |
Comments |
---|---|
Overwrite architecture collected by ansible_facts Choices:
|
|
List of custom checks Default: |
|
List of architectures on which check will be executed Default: |
|
List of cloud providers on which check will be executed Default: |
|
Condition to run check Conditions should use only variables that are provided in checks execution context. ansible_facts and cluster_properties variables are provided in checks execution context. ansible_facts are collected for the host where role is executed, so if you are analyzing local xml export of the cluster CIB, ansible_facts will be collected for the host where you are running the role (for instance localhost). More variables will be provided in checks execution context. Checks are automatically filtered based on the following criteria ‘architecture’ variable - either provided as role parameter, or collected from ansible_facts ‘platform’ and ‘version’ variables - either provided as role parameters, or collected from ansible_facts ‘cloud_provider’ - not yet supported. Checks filtered out this way will not be even in the main check loop. Another way to filter checks is to use tags. See pcs_config_checks_tags_exclude parameter. If there is a more complex condition when to execute check and when not,
this condition should be provided individually for each check in parameter when.
For instance, this is how to ignore checks on an odd numbered day.
{% raw %}
name: This check will be executed only on even numbered days and will fail.
condition: false
when: “{{ ansible_facts[‘date_time’][‘day’] | int % 2 == 0 }}”
{% endraw %}
Check will be marked as skipped and not executed if ‘when’ condition is Default: |
|
Documentation for the check |
|
Message to print if check fails Default: |
|
Choices:
|
|
Name of the check |
|
Platform on which check will be executed Platform specification as in ansible collections meta/main.yml file Default: |
|
Priority of the check Choices:
|
|
If this is true, the check will be executed quietly Choices:
|
|
Remediation for the check |
|
Severity of the check Choices:
|
|
Message to print if check succeeds Default: |
|
Tags for the check Default: |
|
If this condition is true, the check will be executed Choices:
|
|
If this is If this is Choices:
|
|
Indicate what will be displayed in loop when executing checks Choices:
|
|
Role execution mode Debug provides more information about the checks and execution context Assert is the default mode Choices:
|
|
Overwrite platform collected by ansible_facts |
|
Name of the platform Choices:
|
|
Version of the platform Choices:
|
|
List of preconfigured checks Default: |
|
List of architectures on which check will be executed Default: |
|
List of cloud providers on which check will be executed Default: |
|
Condition to run check Conditions should use only variables that are provided in checks execution context. ansible_facts and cluster_properties variables are provided in checks execution context. ansible_facts are collected for the host where role is executed, so if you are analyzing local xml export of the cluster CIB, ansible_facts will be collected for the host where you are running the role (for instance localhost). More variables will be provided in checks execution context. Checks are automatically filtered based on the following criteria ‘architecture’ variable - either provided as role parameter, or collected from ansible_facts ‘platform’ and ‘version’ variables - either provided as role parameters, or collected from ansible_facts ‘cloud_provider’ - not yet supported. Checks filtered out this way will not be even in the main check loop. Another way to filter checks is to use tags. See pcs_config_checks_tags_exclude parameter. If there is a more complex condition when to execute check and when not,
this condition should be provided individually for each check in parameter when.
For instance, this is how to ignore checks on an odd numbered day.
{% raw %}
name: This check will be executed only on even numbered days and will fail.
condition: false
when: “{{ ansible_facts[‘date_time’][‘day’] | int % 2 == 0 }}”
{% endraw %}
Check will be marked as skipped and not executed if ‘when’ condition is Default: |
|
Documentation for the check |
|
Message to print if check fails Default: |
|
Choices:
|
|
Name of the check |
|
Platform on which check will be executed Platform specification as in ansible collections meta/main.yml file Default: |
|
Priority of the check Choices:
|
|
If this is true, the check will be executed quietly Choices:
|
|
Remediation for the check |
|
Severity of the check Choices:
|
|
Message to print if check succeeds Default: |
|
Tags for the check Default: |
|
If this condition is true, the check will be executed Choices:
|
|
List of tags to exclude If check has tag from this list, it will not run Checks with tag ‘skip’ will never run Only first **five** elements from this list are used, all other are ignored Default: |
|
If this Affects both debug and assert modes If set to If set to Choices:
|