Allow users to specify a Vagrantfile

[sethvargo]

Allow users to specify a Vagrantfile

[tknerr]

What about #35 here? Guess you theoretically could set require_chef_omnibus = false in .kitchen.yml but then still use the vagrant-omnibus plugin in the Vagrantfile

[sethvargo]

@tknerr please see my comment on #35 - that's not a thing that this driver handles anymore. It's just cruft from earlier revisions. THat's all handled by TK now.

[tknerr]

@sethvargo seen the comment, was just thinking whether this was possible in theory

Btw: I guess we would still need #48 (re-open?). Providing a custom Vagrantfile is just one part of the story, but you still need the plugins installed...

[sethvargo]

@tknerr the end user needs to mange those plugins. But ultimately Test Kitchen doesn't use them. It calls vagrant up --no-provision and then treats the machine as a remote machine over SSH... I don't see how this is something tha Kitchen Vagrant needs to support/care about...

[nitinmohan87]

@sethvargo If I understood correctly, kitchen-vagrant runs Vagrant from a "sandboxed" directory. Even if we have the vagrant plugins installed beforehand, kitchen-vagrant does NOT use them because the "sandboxed" Vagrant have no knowledge of the plugins. #48 addresses this issue when we set use_vagrant_provision to true. It makes sure kitchen tests (which runs Vagrant) have all the necessary plugins installed for the tests.

[tknerr]

@sethvargo so the use_vagrant_provision option has been removed?

If you can specify a custom Vagrantfile, and you want to use plugins e.g. like vagrant-cachier (#37), the having bindler manage these plugins is a great thing. In many cases the end user can not really manage these plugins because specific Vagrantfiles expect specific plugins and plugin versions, and this is what bindler provides a solution for.

I totally understand the reasons why TK uses vagrant only for bringing up the machine and then uses it as any other remote machine via SSH. Makes perfect sense.

I'm just saying: if you give users the opportunity to specify a custom Vagrantfile to "extend" that behaviour, then it should come along with bindler support (#48) -- otherwise you catch only half of the cases imho...

[sethvargo]

@nitinmohan87 kitchen vagrant does not "run" vagrant. It used to, and I think that's what is causing confusion here. use_vagrant_provision is no longer a valid option.

To quote what @fnichol and I just talked about:

Maybe this should just use VBoxManage instead...

Having the vagrant plugins doesn't really provide benefit because we aren't executing them...

[tknerr]

@sethvargo well, at least some of the plugins e.g. vagrant-cachier hook in to 'vagrant-up' already, so they provide immediate benefit even without 'vagrant provision'

[sethvargo]

In which case you can specify a custom Vagrantfile and install the plugin yourself

[tknerr]

@sethvargo: yes, 👍 for custom Vagrantfile, totally!

But still you would need bindler support (#48) otherwise it's not really usable for a majority of cases imho.

As an example, consider a build server which runs test kitchen for several projects with a custom Vagrantfile each. Two problems:

1. everytime a new project is added which uses a not yet globally installed plugin it will fail. So you have to actually log in and install the new plugin manually.
2. there will be projects which have different plugin requirements. Without bindler you can install plugins only globally and you can not install two different versions of the same plugin (Vagrant does not allow that)

Bindler solves exactly the above two problems by installing the required plugins (as specified in plugins.json) in the project-local .vagrant directory. The only global plugin you ever need to install is bindler, everything else will be automagically installed as required on a per-project basis. Hassle-free and no more manual installation of plugins required.

[sethvargo]

@tknerr right, but there's nothing stopping you from creating a kitchen-vagrant-bindler driver that inherits from kitchen-vagrant and adds this functionality. This driver is designed to be the simplest and easiest to use.

[tknerr]

@sethvargo ok, I see your point now... Sounds reasonable :-)

[nitinmohan87]

@sethvargo I am really interested in seeing progress on this feature. It should definitely be super-helpful for users to specify custom Vagrantfiles. Is there any ETA decided for this?

It would be nice if the README is updated asap to remove deprecated parameters so that new users don't start to actually use it now and then see them gone in the near future.

[sethvargo]

@nitinmohan87 I removed all the Berkshelf-related things. For now, everything else "works". And this change will be a major release, so you can saftely follow semver and not break things.

[johndesp]

I am real close to getting test-kitchen to work with a Windows box. However, vagant is trying to establish an ssh connection. Ultimately, the converge fails. However, I can rdp and winrm to the box.

What .kitchen.yml setting canI use to instruct kitchen to instruct vagrant to not execute the ssh connection?

thanks

Finished creating (2m0.81s).
-----> Converging ...
[SSH] connection failed, retrying (#<Net::SSH::Disconnect: connection closed by remote host>)
[SSH] connection failed, retrying (#<Net::SSH::Disconnect: connection closed by remote host>)
$$$$$$ [SSH] connection failed, terminating (#<Net::SSH::Disconnect: connection closed by remote host>)

Converge failed on instance .
Please see .kitchen/logs/default-windows20008R2.log for more details
------Exception-------
Class: Kitchen::ActionFailed
Message: connection closed by remote host

[tmatilai]

As you most probably want to use vagrant-cachier, vagrant-proxyconf, etc. in all your (local) VMs, it's normally best to configure them globally in ~/.vagrant.d/Vagrantfile (see "Load Order and Merging" in the docs).

[fnichol]

Sorry to have been quiet on this issue, @sethvargo's pretty much covering what I'd have to say.

This is what I'm thinking: a driver configuration option, maybe vagrantfile_erb that is a path to a Vagrantfile ERB template. We'll render that template and pass it the instance object which gives you access to the Driver config hash, the Provisioner config hash, and even Busser config. You can get instance, suite, platform names, etc. Going to take a look at this now…

[fnichol]

This is implemented by cc75795, please read the commit comment and README updates for more details.

This commit also removes the use_vagrant_provision option as it no longer applies. If you need other middleware to fire then you can break out to a custom Vagrantfile ERB template.

@tmatilai is right on about configuring plugins more globally as this lets you benefit from vagrant-cachier across all Vagrant instances, including Test Kitchen's.

Thanks all!

[fnichol]

Also, e953bfb adds support for a pre_create_command which will execute whatever you want just before vagrant up --no-provision is called. It has a token for the path-to-vagrant-home directory, so if using Binder this could look like:

---
driver:
  name: vagrant
  pre_create_command: cp .vagrant_plugins.json {{vagrant_root}}/ && vagrant plugin bundle