Proposal to remove isolation (caching) support from linter

[ssbarnea]

As the isolation feature from ansible-lint proved to be a permanent source of confusion for its users I would like to propose its removal.

The main reason for the confusion is that what ansible-lint is seeing as being installed/available is not the same thing as what ansible itself does. Basically, ansible called by ansible-lint behaves differently than calling ansible directly.

While this was done by altering collections and role paths in a way that prevents accidental installation (or override) of ansible collections and roles as the user level (~/.ansible).

I think we have a better way of doing this that does not involve the problematic injectstion of ~/.cache/ansible-compat/{checksum} path to ansible include paths.

We can make ansible lint detect if the 1st inclusion path is inside current project directory and avoid performing any installations there and display a warning, telling user that if he wants to auto-install test dependencies they need to create an ansible.cfg find inside current project that tells Ansible to user in-repo locations for collections and roles, like below:

[defaults]
collections_path = .

If we stop using the isolated cache, we can ensure that running ansible-galaxy collection list will display the exact list of collections that also ansible-lint finds and uses.

One downside of dropping the cache is that we might fail to detect some content dependencies that were already installed at user level but user forgot to add them on their test-requirements.yml file. Still, in future versions we might add a feature to note use of any content module that is not listed inside these requirements and notify the user, so the limitation would only time limited. The fact the linter also runs on CI/CD pipelines makes is unlikely to miss that.

PS. Please note that there is no expectated change related to use of "offline" more.

[briantist]

I didn't vote (yet) because I want to clarify some things, but I think I support this proposal.

I don't want to remove any detail in the original post because it's good context, but it would be helpful (for me at least) to also add a short summary of the different possible behaviors, for example:

• if ansible.cfg file exists AND the collections_path is defined AND the first path in the list is part of the current project then:
  • ansible-lint will use ONLY collections in the defined path(s) and will not install anything
• else
  • ansible-lint will install collections that are defined in <requirements-file> (does this need to be a specific name? specific path? is it configurable?) into <which directory?>
  • ansible-lint <will?|will not?> re-use the installed collections between runs

etc., that's just a short example, but I would like a way to determine what behaviors happen when, as I struggle with it a bit even now. A flow chart would be wonderful but text form is fine too.

[ssbarnea]

• We can detect if the first collection and role paths are inside the project and if it is, we can assume it is safe to install requirements.
• If we detect the collection path(s) are outside current project and we need to install requirements, we display a warning message that explains to the user what to do. We continue without installing anything (to avoid altering user level content).
• Between runs ansible-lint will reuse installed collections, that is a critical feature that is still to remain.
• There are several requirement files detected by the linter, not only the root test-requiremetns.yml, no plans to touch that as part of this change.
• Note that one side effect of this is that mocking will happen only when user configured in-repo path. We can think about mocking as being part of installing requirements, it is just another way to create content.

Note that I also plan to add a specific documentation page related to why user should create an ansible.cfg file inside his project, even if that is not used for production purposes. We really need to explain what content isolation is and why this is important for development. Not everyone is aware about this and we need to provide a clear explanation to avoid "but it works on my machine" kind of problem.

[netopsengineer]

@ssbarnea It would be helpful also to understand what aspects of ansible-lint require Collections, I never found documentation that explained why it wanted to install the Collections to begin with, in terms of what features relied on it. I typically chose offline mode, simply from not having a clear understanding of what it meant to let ansible-lint install them, what version would it install, etc.

I tend to fall into the camp that does configure ansible.cfg to have my collections_path pointed to a collections directory located inside each project, and the collections are installed there as part of the project. So your proposal would have me covered well. In the rare instance I do not install them locally, I will still have collections dir local to the project, with requirements.yml in the directory, and let AWX install them.

[ssbarnea]

You are already doing it very well, both cases are covered, and for exactly the same reasons I proposed this change. Basically that is about reducing the dark magic in ansible-lint ;)

I am aware that this proposed change might surprise some users that have only have a user or system level ansible.cfg file. They will see that linter refuses to install requirements for them and ask them to create an in-repo config, which basically takes precedence over their own ansible.cfg file. I see it as a feature, but some might not.

[netopsengineer]

Awesome, thanks for the reply @ssbarnea! I use Ansible mainly for Network devices, around 60,000 devices, all different vendors, models, software versions, different roles in the network, having one ansible.cfg or one version of a Collection went out the door pretty quickly 😆.

The per-project Collections, has its obvious cons, but for me, regression testing from updating one central Collection would be brutal. I appreciate you taking the time to poll the user base!

[mariolenz]

The main reason for the confusion is that what ansible-lint is seeing as being installed/available is not the same thing as what ansible itself does. Basically, ansible called by ansible-lint behaves differently than calling ansible directly.

I don't think I really understand what you are talking about... but at the spur of the moment, I'd say that ansible-lint should work exactly like ansible when it comes to stuff installed/available. Everything else would be confusing.

[ssbarnea]

After a couple of years of injecting additional paths to collection and roles lookup paths, I fully agree with you. While that approached allowed installing content automatically without potentially affecting user level content, it caused a divergence of behavior between ansible itself and how linter worked.

Removing this "feature" and displaying an warning when is not safe to install required content is probably the way forward. Users will only have to create one ansible.cfg file to re-enable auto-provisioning.

Some people prefer to install dependencies manually before linting, those will not be affected by this change.