Molecule: Request Local Driver

[gzm55]

Issue Type

• Feature request

Molecule and Ansible details

ansible --version
2.2.1

molecule --version
1.21.1

• Molecule installation method: pip
• Ansible installation method: OS package

Desired Behaviour

use local driver to test the roles with only tasks/modules/plugins running on the ansible controling machine.

[popstas]

@gzm55, you mean that molecule should can self-provision local machine, without docker and vagrant sandboxes?

I think it can be useful on travis for roles that cannot be tested in docker, like roles that modifies /etc/hosts, /etc/resolv.conf and so on.

[retr0h]

I'm probably not going to implement this into Molecule v1. However, this sounds interesting for v2.

[gzm55]

IMO, it is something like 'connection: local' or 'deletate_to: localhost' in ansible, or 'local' connection backends in testinfra.
Before version 2, can we have options to skip driver section, and do not converge any VM/container instances at all?

[retr0h]

Before version 2, can we have options to skip driver section, and do not converge any VM/container instances at all?

v1 isn't getting much of my time.

[retr0h]

@gzm55 so what is it you are looking for?

You want molecule to entirely skip the creation portion, and one would provide the connection settings in inventory? This would allow a user to point molecule at a server that was managed externally to Molecule for converge,test cycle?

[gzm55]

@retr0h Yes, first we want to avoid depend on ANY VM driver (now a driver and at least one vm/container are always required ) and then skip provisioning ANY virtual machine; second, we need molecule to generate the inventory from molecule.yml, the connections of generating hosts could be localhost, ssh or any other valid ansible connections.

With this feature, we can test some special ansible roles, such as do something only on the ansible controlling machine.

[aroundthecode]

+1 on this.

Being able to provide a custom ansible inventory without any provision would allow test to be run also on the real machine and not just on test ones.

This would sound like a "production" scenario for validating changes even on final machine and be sure they match expected result obtained in "development/regression" scenarios run with provisioned VMs

[retr0h]

@gzm55 @aroundthecode I just implemented a Static driver. This is rough around the edges and will change a bit. Feel free to try it out. Currently, I have prototyped it on Docker running locally. Once I incorporate vagrant, it is likely this will just work for any ssh endpoint.

P.S. Is Static a good name?
P.S.S. I will be force pushing to this branch.

[gzm55]

@retr0h If setting ansible_connection to local, the tests will run directly on the localhost, is it right?

[retr0h]

@gzm55 yes, and the validator (testinfra) will also piggy back on that connection.

[gzm55]

@retr0h this interface looks good to me.

Molecule automatically appends the scenario name to the instances it is testing.

Will this introduce some confusion?

[retr0h]

Will this introduce some confusion?

Hopefully not :) This is how v2 works today. It really wouldn't make sense to have a static host that is managed outside of molecule, and converge various scenarios against it.

The whole beautify of scenarios is the converge/test cycle per scenario.

Also, it should be noted this is a v2 only feature.

[gzm55]

This will not be a problem on vm driver (vagrant/docker/localhost). Whereas for metal machines, maybe we need some example showing how to specify pingalbe hostname via ansible_host.

Another thing,

login_cmd_template: 'docker exec -ti {} bash'

this seems using a syntax like xargs, right? more documents?

[retr0h]

this seems using a syntax like xargs, right? more documents?

This example only covers Docker. Nothing else has been attempted or developed yet.

[retr0h]

Closing. Implemented @ 1b659496f7d9d98c99bacce3e35d7d2f4d952f30.