Molecule: Update molecule's config syntax to be more like test kitchen

[retr0h]

This is a fairly tough job to merge into molecule, however, the config would benefit from following the test kitchen "syntax". Especially b/c testing various scenarios would be beneficial. I have started to prototype this.

This would bump molecule to 2.x as part of the change.

[kireledan]

Im a huge fan of this. 👍 👍 👍

[dhutty]

I'm very much in favour of this, it was the original intent to be as close to test-kitchen's UX as made sense, to default to the kitchen UX and only deviate when necessary or for good reason. In reality, molecule 1.x UX is quite far from kitchen and this would be a breaking change for (almost?) every molecule.yml, so I agree that this is worth a major version bump.

And to go along with that we should be more careful than usual about documenting the upgrade/testing/releasing, but with that caveat: 👍

[tknerr]

+1, would love to see suites support (as long as there can be still multiple instances per suite, which is atm not supported by TK afaik)

[retr0h]

Molecule 2.x config syntax proposal. We would like to use a similar config to test-kitchen. However, we likely cannot be 100% compatible _nor_ do we need to be.

Below is more vagrant specific, but we should try and normalize the config across drivers.

driver:
  name: vagrant
  network:
    - ip: 192.168.50.4
    - type: dhcp
       auto_config: false
  customize:
    memory: 1024
    cpu: 1

provisioner:
  name: ansible
  flag1: foo
  flag2: bar
  env:
    FOO: bar

platforms:
  - name: ubuntu-14.04
     box: ubuntu/trusty64
  - name: ubuntu-12.04
     box: hashicorp/precise64

suites:
  - name: scenario-1
     run_list:
       playbook.yml

How do we represent multiple-instances? Test kitchen combines the suite and platform to create a set of tests it loops through.

I was thinking we treat platforms as instances. The number of systems listed in platforms == the number of instances we converge. We then combine that with the suites, so we can create scenario basted testing.

So this would effectively become.

platforms:
  - name: ubuntu-14.04
     box: ubuntu/trusty64
  - name: ubuntu-12.04
     box: hashicorp/precise64

suites:
  - name: scenario-1
     run_list:
       playbook1.yml
  - name: scenario-2
     run_list:
       playbook2.yml

1. Create 2 instances
2. Converge both instances using the playbook from scenario-1
3. Perform the tests associated with scenario-1.
4. Destroy the instances
5. Start again with scenario-2.

I don't see much value in targeting a particular platform. Is that really necessary or useful? How would we represent that in the config.

[chrisplo]

Some thoughts:
I think scenarios should be able to specify one or a list of extra var files.

I think your suite should be able to control which platforms, might be better to have platforms as a map of name->data instead of list of maps, would facilitate a later platform set concept but short term suite can optionally set a list of platforms to override the default of using all of them.

Suites might be better in the map of name->data as well, then you have the later option to attribute the suites in other data structures for whatever reason in the future.

Redoing a whole VM is a lot of overhead as well, might be nice to describe a series of suites that can be executed against a single instance before teardown like:

scenario (or some better noun):
  - platform: [ubuntu-14.04, ...] # default to all of them
    suite: [scenario-1, ...] # required

Absence of scenarios has the all suites on all platforms behavior

[retr0h]

The config is starting to take shape. Molecule v2 will be much different. Will likely release both v2 and v1.x together, so users who do not wish to use v2 can continue to use v1.x. However, when released, v1.x releases will cease.

https://github.com/retr0h/maquina/blob/v2/molecule/config.py#L141

[retr0h]

This is currently underway with v2 branch. Details were discussed at this PR.

Closing this issue, since the details have been worked out and underway.