community.zabbix icon indicating copy to clipboard operation
community.zabbix copied to clipboard

--skip-tags="always"

Open emper0r opened this issue 2 years ago • 2 comments

SUMMARY

Hi we are using the module and works fine... is just this kind option we are getting some issue.

ISSUE TYPE

in our deployment we use a playbook where load many others groups of playbooks... and we need to add by force this ' --skip-tags="always" ' on runtime when we not deploy zabbix ... and if we need to config zabbix for some server then remove it to can use module correctly with our variables, otherwise the other playbook when ansible load zabbix module get error trying to install zabbix on hosts and of course playbooks ends failed

COMPONENT NAME

zabbix-agent from community.zabbix 1.3.0

ANSIBLE VERSION
ansible 4.3.0
CONFIGURATION
COLLECTIONS_PATHS(/home/emper0r/ansible/ansible.cfg) = ['/home/emper0r/ansible/collections']
DEFAULT_HOST_LIST(/home/emper0r/ansible/ansible.cfg) = ['/home/emper0r/ansible/inventories/devel>
DEFAULT_LOAD_CALLBACK_PLUGINS(/home/emper0r/ansible/ansible.cfg) = True
DEFAULT_STDOUT_CALLBACK(env: ANSIBLE_STDOUT_CALLBACK) = yaml
HOST_KEY_CHECKING(/home/emper0r/ansible/ansible.cfg) = False

OS / ENVIRONMENT / Zabbix Version
STEPS TO REPRODUCE
- name: import aws config (infra)
  import_playbook: aws_devel.yml
  tags: [ infra ]

- name: import aws config (zabbix agent)
  import_playbook: aws_devel_zabbix.yml
  tags: [ zabbix_agent ]


ansible-playbook -u root main_playbook.yml --limit="host_without_zabbix_agent" --tags="infra" --skip-tags="always"  
ansible-playbook -u root main_playbook.yml --limit="host_with_zabbix_agent"
EXPECTED RESULTS

No use on runtime ' --skip-tags="always" '

ACTUAL RESULTS

Trying to install zabbix-agent into all hosts where isn't zabbix agent configured.


emper0r avatar Oct 04 '21 10:10 emper0r

Hi,

The tag always is part of Ansible and is a common usage pattern when using tags. I don't see the point of removing the always tags and add more maintenance work in the roles and thus not relying on common practices for a single user. I also experience tags as in something specific for a environment/client/customer: everyone has an idea what works best for them which might be not working for someone else. I personally find tags counterintuitive, it prevents a role to be executed without any further knowledge on a system. I would always run ansible-playbook -u root main_playbook.yml, otherwise I would have used ansible-playbook -u root infra_playbook.yml and thus only install the "infra" roles.

If more users needs or wanting this change I am open to get a PR (for all roles to be consistent in this collection) and merge it.

dj-wasabi avatar Oct 04 '21 11:10 dj-wasabi

Hi @dj-wasabi, As you I also think ansible tags are very hard to manage and often counterintuitive, but still useful and powerful.

Tags will work differently under import vs include and sure as @emper0r say, with import_playbook, but I think this issue is more related to the meaning of always that was implemented as a special tag to execute a task even if Ansible was called with --tags option, so even if one want to limit to specific tasks with --tag if your role is part of a play will always execute internal tasks marked as always ans one must add --skip-tag "always" that is not natural (also import_playbook is part of Ansible and is a common usage pattern).

If you are really sure this is what you want all users using import and your role cannot run a play contaning your role without adding --skip-tag

@emper0r sample seems a common pattern to deploy on complex infra with many components allowing to choose what components update/change but allowing if one need to update entire infra configuration.

Roxyrob avatar Oct 04 '21 12:10 Roxyrob