'Validates arguments passed to ansible-playbook with a defined argument specification

We want to run the following playbook with the yml file - ansible-playbook install_os.yml

The playbook install_os.yml is working well , but now we want to add the validation of the arguments <machine name>,<machine IP>.

As the following:

ansible-playbook install_os.yml --limit RHEL01,73.22.3.44

From my point both arguments should be identify as strings (without verify of valid IP) and between <machine name> to <machine IP>, we should set the , separator

So, is it possible to validate the strings? And exit if one of them or both them are not defined?



Solution 1:[1]

You can access the limit specified in arguments to ansible-playbook with the help of the special variable ansible_limit.

From there on, you can assert the --limit values based on your business needs.

For example:

- hosts: all
  gather_facts: no

  tasks:
    - assert: 
        that: 
          ## We have exactly one comma, separating two hosts
          - ansible_limit | split(',') | length == 2
          ## We have a string before the comma
          - (ansible_limit | split(',')).0 is string
          ## We have a non-empty string before the comma
          - (ansible_limit | split(',')).0 | length > 0
          ## We have a string after the comma
          - (ansible_limit | split(',')).1 is string
          ## We have a non-empty string after the comma
          - (ansible_limit | split(',')).1 | length > 0
          ## 'all', which has a wildcard meaning, 
          ## is not one of the two hosts separated by the comma
          - "'all' not in ansible_limit | split(',')"
          ## We do not have any character having a special meaning in the limit
          ## see: https://docs.ansible.com/ansible/latest/user_guide/intro_patterns.html#common-patterns
          - "'@' not in ansible_limit"
          - "':' not in ansible_limit"
          - "'!' not in ansible_limit"
          - "'&' not in ansible_limit"
          - "'*' not in ansible_limit"
      run_once: true

This would probably limit it to the use case you want.
This said, mind that --limit is an existing flag with its own behaviour, so, based on what you are aiming for, you could also be better with an extra parameter passed in command line.

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1