Allow configuration of install_local bool in prerun

[Nubly]

Issue Type

• Bug report

Molecule and Ansible details

(ansible-2.12.x) [nubly@ansible_host test_role]$ ansible --version && molecule --version
ansible [core 2.12.3]
  config file = /home/nubly/Git/ansible/ansible.cfg
  configured module search path = ['/home/nubly/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/nubly/.venvs/ansible-2.12.x/lib/python3.9/site-packages/ansible
  ansible collection location = /home/nubly/Git/ansible/collections
  executable location = /home/nubly/.venvs/ansible-2.12.x/bin/ansible
  python version = 3.9.2 (default, Jan 19 2022, 12:26:41) [GCC 11.1.0]
  jinja version = 3.0.3
  libyaml = True
molecule 3.6.1 using python 3.9
    ansible:2.12.3
    delegated:3.6.1 from molecule
    podman:1.1.0 from molecule_podman requiring collections: containers.podman>=1.7.0 ansible.posix>=1.3.0

Molecule installation method:

• pip

Ansible installation method:

• pip

Detail any linters or test runners used:

• molecule
• ansible-lint
• yamllint
• flake8

Desired Behavior

No symlink being left within the roles dir post-molecule action. Perhaps by way of a configuration option, or a flag.

Actual Behaviour

(ansible-2.12.x) [nubly@ansible_host test_role]$ molecule dependency
INFO     default scenario test matrix: dependency
INFO     Performing prerun...
INFO     Set ANSIBLE_LIBRARY=/home/nubly/.cache/ansible-compat/b09132/modules:/home/nubly/.ansible/plugins/modules:/usr/share/ansible/plugins/modules
INFO     Set ANSIBLE_COLLECTIONS_PATH=/home/nubly/.cache/ansible-compat/b09132/collections:/home/nubly/Git/ansible/collections
INFO     Set ANSIBLE_ROLES_PATH=/home/nubly/.cache/ansible-compat/b09132/roles:/home/nubly/Git/ansible/roles/external:/home/nubly/Git/ansible/roles/internal:/home/nubly/.venvs/ansible-2.12.x/share/ansible/roles
INFO     Using /home/nubly/Git/ansible/roles/internal/test.test_role symlink to current repository in order to enable Ansible to find the role using its expected full name.
INFO     Running default > dependency
WARNING  Skipping, missing the requirements file.

(ansible-2.12.x) [nubly@ansible_host test_role]$ ls -l ../
total 0
drwxr-xr-x  7 nubly root 124 Mar  9 16:13 test_role
lrwxrwxrwx  1 nubly root  73 Mar 10 13:19 test.test_role -> /home/nubly/Git/ansible/roles/test_role

Misc Info

This was discussed a bit in issue #3404 and pull request #3409.

My ansible environment consists of a large amount of roles within the same directory.

All roles which I have developed only depend on other roles I have developed, and thus there really isn't a need for me to use a namespace as I also do not publish them to Galaxy. It's a bit silly for me to have to worry about Galaxy naming requirements when I will not publish anything from my environment to Galaxy.

Since the install_local boolean was hardcoded True within #3409, on every Molecule action in which the prerun takes place, Molecule is creating symlinks
to roles which are already installed in the ANSIBLE_ROLES_PATH as a result of the prepare_environment() function continuing past the install_local check and then calling _install_galaxy_role.

The _install_galaxy_role function is also the only reason I am using a namespace, as it exits with an error by default if my role names are not up to spec even though they don't have to be.

At first, I thought that I could change my role directory naming convention to $namespace.$role_name to prevent this, but then I was met with ansible-compat #97.

I still want to be able to install requirements from requirements.yml, and as such I am unable to explicitly disable the prerun. However, I'd like to be able to disable the Galaxy role installation steps as I know that my any/all roles needed in my roles are present in my roles path and able to be found, as setting the boolean within the code to False results in my tests still running as they should.

I'd like to be able to specify a flag from CLI or configuration option within molecule.yml or some other applicable file to allow the value of the install_local boolean to be configured within Molecule's prerun, thereby allowing configuration of the creation of these symlinks (and installation of Galaxy roles). There was a small amount of discussion on this on #3409.

[zhan9san]

Hi @Nubly

At first, I thought that I could change my role directory naming convention to $namespace.$role_name to prevent this, but then I was met with ansible/ansible-compat#97.

Could you verify whether both #3514 and ansible/ansible-compat#135 clear your concerns?

I still want to be able to install requirements from requirements.yml, and as such I am unable to explicitly disable the prerun. However, I'd like to be able to disable the Galaxy role installation steps as I know that my any/all roles needed in my roles are present in my roles path and able to be found, as setting the boolean within the code to False results in my tests still running as they should.

Yes. If prerun is disabled, besides the current role installation(a symlink), the requirements would not be installed either.

If both PRs are merged, the requirements would be installed in an isolated directory, which is similar to how Python virtual env and npm node_modules do.

[Nubly]

Hi, @zhan9san.

#3514 does indeed mitigate my issue, but not necessarily at the source. My issue would be better solved by avoiding symlinks being created whatsoever, not just moving them to a cache dir.

In my environment, which is perhaps a bit atypical, I had some additional tooling acting as an interface to my Ansible roles. I've since changed that tooling to accomodate for the symlinks, but they're still a bit annoying as I've got two directories for each of my roles in my ANSIBLE_ROLES_PATH due to molecule, but your pull requests should solve that.

I had thought that allowing configuration of the install_local boolean would be a preferable change, as I did here in my fork, but I see things have been changing around a bit with respect to the prepare_environment function within ansible-compat as well as my environment since I opened this issue, and I'll have to reevaluate if this is worth submitting an actual pull request for.

In short - yes, those pull requests you mentioned do indeed mitigate my issues. Thanks.

[zhan9san]

@Nubly

I am glad to hear that it works for you.

#3514 is mainly for #3495 and it happened to address this issue as well.

[ssbarnea]

#3569 should have fixed that one