Incorrect recommendation: fqcn[canonical]: You should use canonical module name kubernetes.core.k8s_info instead of kubernetes.core.k8s.

[lucastheisen]

Summary

Getting a false recommendation to convert k8s to k8s_info

fqcn[canonical]: You should use canonical module name `kubernetes.core.k8s_info` instead of `kubernetes.core.k8s`.

Issue Type

• Bug Report

OS / ENVIRONMENT

ansible-lint 24.5.0 using ansible-core:2.13.9 ansible-compat:24.5.1 ruamel-yaml:0.18.6 ruamel-yaml-clib:0.2.8

• ansible installation method: one of source, pip, OS package
  pip

• ansible-lint installation method: one of source, pip, OS package
  pip

STEPS TO REPRODUCE

(mitre-wsl-rocky9) ltheisen@MM269697-PC ~/tmp/ansible-lint-4172
$ docker build --progress plain - <<'DOCKERFILE'
FROM python:3.10

WORKDIR /opt/app

RUN curl -ksSL https://gitlab.mitre.org/mitre-scripts/mitre-pki/raw/master/os_scripts/install_certs.sh | sh
RUN python -m pip install --upgrade pip
RUN python -m pip install ansible-core ansible-lint kubernetes
RUN ansible --version
RUN ansible-lint --version
RUN ansible-galaxy collection install kubernetes.core:==2.2.0

COPY <<EOF /opt/app/roles/lint_repro/tasks/main.yml
---
- name: Repro for linter fail on k8s -> k8s_info
  kubernetes.core.k8s:
    definition:
      apiVersion: v1
      kind: ServiceAccount
      metadata:
        name: name
    state: present
EOF

RUN ansible-lint --offline --force-color roles/lint_repro/tasks/main.yml
DOCKERFILE

Desired Behavior

...
Passed: 0 failure(s), 0 warning(s) on 1 files.

Possible security bugs should be reported via email to security@ansible.com

Actual Behavior

Please give some details of what is happening. Include a minimum complete
verifiable example with:

• minimized playbook to reproduce the error
• the output of running ansible-lint including the command line used
• if you're getting a stack trace, also the output of
  ansible-playbook --syntax-check playbook

...
 > [10/10] RUN ansible-lint --offline --force-color roles/lint_repro/tasks/main.yml:
2.806 fqcn[canonical]: You should use canonical module name `kubernetes.core.k8s_info` instead of `kubernetes.core.k8s`.
2.806 roles/lint_repro/tasks/main.yml:2 Task/Handler: Repro for linter fail on k8s -> k8s_info
2.806
2.810 Read documentation for instructions on how to ignore specific rule violations.
2.815
2.817                 Rule Violation Summary
2.817  count tag             profile    rule associated tags
2.817      1 fqcn[canonical] production formatting
2.817
2.818 Failed: 1 failure(s), 0 warning(s) on 1 files. Last profile that met the validation criteria was 'shared'. Rating: 4/5 star

[lucastheisen]

Well, i'm gonna guess the answer might just be that I have to upgrade my version of kuberentes.core, but it does seem odd that the only thing that changed in my project was ansible-lint got upgraded and this issue triggered. Could be that ansible-lint fixed an internal bug that prevented this fqcn from actually performing a check that if checked would have pointed this out earlier... Not sure, but y'all are prolly gonna wanna just close this as: "you need to upgrade your kubenetes.core"

[jiholland]

Same issue with cisco.ios (v8.0.0) and cisco.nxos (v8.0.0) collections.
Example:
fqcn[canonical]: You should use canonical module name cisco.nxos.nxos instead of cisco.nxos.nxos_facts.

ansible-lint 24.5.0 using ansible-core: 2.16.6

[lucastheisen]

Well i found the issue for my specific case, turns out that the kubernetes.core module removed "a hack" they had in place that was explicitly configuring redirects. Using a version of kubernetes.core after that hack was removed will no longer trigger this finding. So from the ansible-lint front, something in version 24.5.0 actually started looking at this old "hack" configuration in kubernetes. I have been unable to grok the change in ansible-lint, though what i did see looks buggy.

[lucastheisen]

@jiholland , it appears your cisco collection has the same "old hack" that the kubernetes collection was using. It appears to have been removed in January, so probably already part of a release. An upgrade of your collection will probably resolve this for you.

That said, this hack appears to be a normal thing that multiple large collections used. Might be a good idea to account for this somehow in the linter (like im not sure whether this is a valid finding or not given that these 2 large collections use it). At minimum it would be nice if the documentation were updated to state that if you run into this you should check your collections meta/runtime.yaml for redirect's