Upgrade fqcn-builtins rule into fqcn

[ssbarnea]

• rename tag from fqcn-builtins to fqcn[action-core] and add alias
• update documentation with examples
• add fqcn[action] for those that are not using known builtins
• documented fqcn[action-redirect] for redirects (implementation in follow-up)
• added the two new checks default warn_list

[trishnaguha]

@ssbarnea Can we also update this doc with FQCN?

[ssbarnea]

@ssbarnea Can we also update this doc with FQCN?

This includes changing documentation.

[samccann]

@ssbarnea - why change to action-internal? From an external perspective (aka I don't deal with lint much - when you say fqcn-builtin - I know what you're talking about - the builtin modules in core. Changing it to action-internal, frankly, made me go check to see do we have some 'action plugins' I didn't know about?

[ssbarnea]

@samccann That was after I had a chat yesterday with @bcoca and looked at the fact that the remediation of the error is to add either ansible.legacy. or ansible.builtin. prefixes. Using builtin was seen bit misleading, especially as the default behavior of ansible is to use the legacy one when the fqcn is absent. Especially as this rule was out for a long period of time I do find builtin easier to understand. Few others from my team mentioned the same, so we might be going for fqcn[builtin-action] to make even more natural.

Keep in mind that in the near future we will also see fqcn[filter] and fqcn[filter-builtin] as filters have the same challenge. Let me go back to him to see if that would be ok.

If someone ever claims that naming is easy, they should start to contribute to the linter. Sometimes we need to spend more time on naming than in implementing the code for it.

[bcoca]

filters, tests, lookups, strategy .. in the end any plugin that can appear in a playbook

[samccann]

Ok read the docs section in the PR a bit more. I understand the need to distiguish between ansible.builtin and ansible.legacy but now I'm confused why we are calling modules actions now?

[bcoca]

modules are the code that 'most of the time' runs because of actions, tasks have always had actions:

action: module=X was the original way to write them (also local_action: module=X), then for shorthand we added action: X ... then even shorter X: but it is always 'the task action' .. which uses an action plugin that CAN but does not require, using a module (though most of the time you end up using a module).

[hswong3i]

@ssbarnea I have a role (https://github.com/alvistack/ansible-role-ceph_mon) with custom library:

$ tree tasks/ library/
tasks/
├── debian.yml
├── main.yml
├── redhat.yml
└── suse.yml
library/
└── ceph_key.py

And so I reference my custom library from tasks/main.yml as below (https://github.com/alvistack/ansible-role-ceph_mon/blob/master/tasks/main.yml#L109-L126):

- name: create mon. keyring
  ceph_key:
    name: "{{ item.name }}"
    dest: "{{ item.dest }}"
    caps: "{{ item.caps | default(omit) }}"
    owner: "{{ item.owner | default('ceph') }}"
    group: "{{ item.group | default('ceph') }}"
    mode: "{{ item.mode | default('0400') }}"
    state: "present"
    import_key: false
  loop:
    - name: "mon."
      dest: "/var/lib/ceph/tmp/ceph.mon.keyring"
      caps: { mon: "allow *" }
  when: inventory_hostname == ansible_play_hosts[0]
  delegate_to: "{{ ansible_play_hosts[0] }}"
  notify:
    - ceph_mon | systemctl restart ceph-mon.target

With this new rule I could only manage to disable the check for it now with # noqa fqcn[action].

Any suggestion for not doing such skip, but rewrite to a correct syntax with our up-to-date standard?