Molecule: v3.1.1 regression: {'driver': [{'name': ['unallowed value docker']}]}

[micheelengronne]

Issue Type

• Bug report

Molecule and Ansible details

ansible 2.10.1 && molecule 3.1.1

Molecule installation method (one of):

• pip

Ansible installation method (one of):

• pip

Desired Behavior

molecule should pre-validate.

Actual Behaviour

molecule v3.1.1 fails with this error:

ERROR: Failed to pre-validate.
{'driver': [{'name': ['unallowed value docker']}]}

[bhean]

I think this is the reason: https://github.com/ansible-community/molecule/pull/2811
Docker driver is now "out" of Molecule core, so you have to install it apart:

pip3 install molecule-docker

[chrisjsewell]

yeh I think you should have made this a 4.0.0, because thats very much a breaking change lol

[bhean]

yeh I think you should have made this a 4.0.0, because thats very much a breaking change lol

Totally agree... I have more than a dozen different pipelines broken because that... 😞

[ltalirz]

I have more than a dozen pipelines broken because that... 😞

Same here... any chance this can be reverted in a patch release and moved to 4.0?

[chrisjsewell]

I think in one fell swoop you have literally broken everyone's molecule tests
The PR is even labelled as major 🤦

[bhean]

@GR360RY, try setting pre_build_image: true in the platform section of your molecule.yml.

[GR360RY]

@GR360RY, try setting pre_build_image: true in the platform section of your molecule.yml.

@bhean , Thanks this indeed fixed the below issue for me!

    TASK [Create Dockerfiles from image names] *************************************
    task path: /usr/local/lib/python3.8/site-packages/molecule_docker/playbooks/create.yml:34
    Friday 16 October 2020  21:35:12 +0300 (0:00:00.725)       0:00:00.872 ********
    <127.0.0.1> ESTABLISH LOCAL CONNECTION FOR USER: greg
    <127.0.0.1> EXEC /bin/sh -c 'echo ~greg && sleep 0'
    <127.0.0.1> EXEC /bin/sh -c '( umask 77 && mkdir -p "` echo /Users/greg/.ansible/tmp `"&& mkdir "` echo /Users/greg/.ansible/tmp/ansible-tmp-1602873312.3012-75580-93479983521941 `" && echo ansible-tmp-1602873312.3012-75580-93479983521941="` echo /Users/greg/.ansible/tmp/ansible-tmp-1602873312.3012-75580-93479983521941 `" ) && sleep 0'
    <127.0.0.1> EXEC /bin/sh -c 'rm -f -r /Users/greg/.ansible/tmp/ansible-tmp-1602873312.3012-75580-93479983521941/ > /dev/null 2>&1 && sleep 0'
    failed: [localhost] (item={'command': '', 'docker_networks': [{'ipam_config': [{'gateway': '10.11.0.254', 'subnet': '10.11.0.0/16'}], 'name': 'bind'}], 'environment': {'container': 'docker'}, 'hostname': 'ns1', 'image': 'geerlingguy/docker-centos7-ansible:latest', 'name': 'ns1', 'networks': [{'ipv4_address': '10.11.0.1', 'name': 'bind'}], 'privileged': True, 'tty': True, 'volumes': ['/sys/fs/cgroup:/sys/fs/cgroup:rw']}) => {
        "ansible_index_var": "i",
        "ansible_loop_var": "item",
        "changed": false,
        "i": 0,
        "item": {
            "command": "",
            "docker_networks": [
                {
                    "ipam_config": [
                        {
                            "gateway": "10.11.0.254",
                            "subnet": "10.11.0.0/16"
                        }
                    ],
                    "name": "bind"
                }
            ],
            "environment": {
                "container": "docker"
            },
            "hostname": "ns1",
            "image": "geerlingguy/docker-centos7-ansible:latest",
            "name": "ns1",
            "networks": [
                {
                    "ipv4_address": "10.11.0.1",
                    "name": "bind"
                }
            ],
            "privileged": true,
            "tty": true,
            "volumes": [
                "/sys/fs/cgroup:/sys/fs/cgroup:rw"
            ]
        },
        "msg": "Could not find or access '/usr/local/lib/python3.8/site-packages/molecule_docker/playbooks/../../../../data/Dockerfile.j2' on the Ansible Controller.\nIf you are using a module and expect the file to exist on the remote, see the remote_src option"
    }

[darkwizard242]

Install it as python3 -m pip install molecule[docker] (that should fix it)... It's been taken out of the core from 3.1.0 onwards.

[ccamacho]

Got the same issue but with podman, I installed molecule-podman and the error moved forward, now, I'm hitting this.

    TASK [Gathering Facts] *********************************************************
fatal: [instance]: UNREACHABLE! => {"changed": false, "msg": "Authentication or permission failure. In some cases, you may have been able to authenticate and did not have permissions on the target directory. Consider changing the remote tmp path in ansible.cfg to a path rooted in \"/tmp\". Failed command was: ( umask 77 && mkdir -p \"` echo ~/.ansible/tmp/ansible-tmp-1602926472.4586434-226978581953627 `\" && echo ansible-tmp-1602926472.4586434-226978581953627=\"` echo ~/.ansible/tmp/ansible-tmp-1602926472.4586434-226978581953627 `\" ), exited with result 125", "unreachable": true}

This is how my converge.yml looks like:

- name: Converge
  hosts: all
  tasks:
    - name: Message for "kubeinit_apache"
      debug:
    msg: Finishing molecule for "kubeinit_apache"

And my molecule.yml:

---
dependency:
  name: galaxy
driver:
  name: podman
platforms:
  - name: instance
    image: docker.io/pycontribs/centos:8
    pre_build_image: true
provisioner:
  name: ansible
verifier:
  name: ansible

Also, I'm running them using pytest like:

python3 -m pytest \
        --color=no \
        --html=${HOME}/reports.html \
        --self-contained-html

But if I go inside the role and execute molecule test I got the same exact issue. It looks like I'm still missing a binding somewhere @sshnaidm @ssbarnea any idea?

I have all my molecule tests BrOkEn Thanks!

[ccamacho]

@sshnaidm @ssbarnea I moved the driver from podman to docker for testing and it worked fine, so I assume there is a regression in molecule-podman making it break like that, my workaround is basically to discard podman in favor of docker.

[ssbarnea]

The top version number will be touched only for marketing purposes. We use the same semantic as Ansible, where the X.Y is what defines a major version.

Release notes and documentation do mention that now you need to install the drivers for podman and docker as they are not installed by default. You can either use the two extras or directly mention the plugin packages.

@ccamacho Take a look at https://github.com/openstack/tripleo-quickstart-extras/blob/master/molecule-requirements.txt#L10 -- this is how you should install python packages, always keeping a range. The range depends on project policy on changing versions. Since previous version was 3.0, it was easy to confuse but if you looks back at 2.x changes, you will see that each X.Y version counted as major.

I recently had to fix docker driver, I will try to take a look at podman one now.

[bhean]

I disagree about the purposes of the "top" version you mention. According to the "Semantic Versioning" specification, if a new release introduce a breaking-change (like this), you should increase this top version to avoid the problems reported on this post.

I know you mention that in a pair of previous releases, but its impossible to me read the changelog of every application, tool or library involved in my software looking for some incompatible change, that's the reason because "I trust" in the semver specification...

I'm very grateful with your work in this (and many others) extremely useful projects, but IMHO I think you should increase the top version when you are merging changes that could potentially broke a lot of other projects.

[chrisjsewell]

The top version number will be touched only for marketing purposes. We use the same semantic as Ansible, where the X.Y is what defines a major version.

Yep agree with @bhean, https://semver.org/ is very clear on what semantic versioning is:

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards compatible manner, and
3. PATCH version when you make backwards compatible bug fixes.

if ansible doesn't use this, then that is also wrong

(As above, I'd also note that you guys normally do a great job, that I'm very grateful for thanks 😄)

[ssbarnea]

We are also right... we count versions starting with 0, not 1:

1. EPOCH/ERA ...
2. MAJOR ...
3. MINOR ...
4. PATCH ...

:D

[chrisjsewell]

then shouldn't your versioning be 3.1.1.0? 😉

[ssbarnea]

It is a silent zero! ;)

[ccamacho]

@ssbarnea ++ for splitting this, we do it, we fix it if it breaks and we continue... The only thing is that we might have a regression in molecule-podman, (I was only able to fix this issue in molecule-docker and not in molecule-podman) otherwise thanks a lot for this change.

[chrisjsewell]

Out of interest, what is the definition of an EPOCH!? When does Ansible decide to move from 2 to 3?

[ssbarnea]

I am closing the ticket to avoid confusing people about a documented change in 3.1.

@chrisjsewell The epoch part was more of a joke, but reality may prove it more real than it was intended. I am not part of Ansible organization and while I know there were lots of voices asking for 2.10 to be named as 3.0, they decided to keep going on 2.x for the forseable future.

If anyone want to make a PR to update the docs regarding versioning of molecule I will be happy to review it. Yes, 1.2.3 will only contain bugfixes for the 1.2.x versions but 1.3.0 will always contain stuff that can break 1.2.x users. In fact bumping middle number is determined by the presence of a breaking change (major label).

[T2L]

In fact bumping middle number is determined by the presence of a breaking change (major label).

With all the respect @ssbarnea - you are not using semantic versioning in the right way. The middle number represents a minor update. See https://semver.org:

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards compatible manner, and
PATCH version when you make backwards compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

[ashleykleynhans]

In fact bumping middle number is determined by the presence of a breaking change (major label).

With all the respect @ssbarnea - you are not using semantic versioning in the right way. The middle number represents a minor update. See https://semver.org:

Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards compatible manner, and
PATCH version when you make backwards compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

With due respect, a breaking change is NOT backwards compatible.