An ask for Test Kitchen 1.4.0 and Kitchen::Vagrant 0.17.0 pre-releases


#1

Howdy y’alls!

—BEGIN tl;dr—

Guess what? We have a couple of pre-release gems cut today for Test Kitchen, specifically:

  • test-kitchen 1.4.0.beta.2 (beta.1 cut yesterday)
  • kitchen-vagrant 0.17.beta.2 (beta.1 cut yesterday)

Here’s my ask for anyone with time/interest/ability in the next day or 2:

Where ever you use Test Kitchen, give this pair of releases a try. If you don’t care about the Vagrant Driver, then just use the Test Kitchen pre-release. Use it exactly as you would any previous stable release, don’t change anything.

—END tl;dr—

It’s extremely important that this release doesn’t break existing projects, Drivers, and/or Provisioners in the wild. If you find issues, please let myself or Tyler Ball know and file an issue if you can. Linking to a reproducible project and kitchen diagnose —all output (scrubbed for credentials first) is such a big help, you have no idea.

Installing

If you have a Ruby workflow with RubyGems and/or Bundler this won’t be too much work:

Gem install with:

gem install test-kitchen —pre
gem install kitchen-vagrant —pre

Gemfile containing:

gem “test-kitchen”, “~> 1.4.0.beta.2”
gem “kitchen-vagrant”, “~> 0.17.0.beta.2”

If you’re using ChefDK, you might want to give this a spin to update test-kitchen (whipped up last night in a frenzy):

To update the kitchen-vagrant gem, simply:

chef gem install kitchen-vagrant --pre --minimal-deps

Windows!

Note that this release has the much-fabled “Windows guest support” (insert “oooo, ahhhh” here). How do you get started? At the moment getting Vagrant base box images of Windows is still a big pain, but if you have access to one, here are the versions that should “just work”:

Windows with Kitchen::Vagrant

Any Vagrant base box should have vm.communicator = “winrm” and vm.guest = “windows” set by default, otherwise vagrant up will not be able to correctly boot the VM. Note that there are some Windows base boxes out there with vm.communicator = “ssh” set, so plan accordingly.

Assuming you have a Vagrant base box called “windows-2012r2”, you can use a .kitchen.yml similar to:


driver:
name: vagrant

platforms:

  • name: windows-2012r2

suites:

  • name: default

Note that with the updates in kitchen-vagrant you don’t need to set/override a :box, :box_url, :communicator, :guest, :port, :username, or :password. Sane defaults should apply.

For anyone who has tried the windows-guest-support branch, you may have seen extra transport configuration like this:


driver:
name: vagrant

platforms:

  • name: windows-2012r2
    transport:
    name: winrm

suites:

  • name: default

This is what Test Kitchen’s going to give you by default for any platform name starting with /^win/ (case insensitive) so add it, or don’t, it should work either way. If you don’t believe me, run kitchen diagnose against both and note the difference :slight_smile:

Finally, if you use certain Vagrant providers or use private networks in your setup, kitchen-vagrant is not currently able to determine your WinRM port. I’m hoping to fix this with a Vagrant plugin which kitchen-vagrant can use to return it’s WinRM and RDP hostname and port.

Further Reading

You can check out the CHANGELOG for more details/links regarding beta.1 and beta.2:

Happy testing!


Fletcher Nichol
Engineering Lead - Test Driven Infrastructure
CHEF | http://www.chef.io
IRC, Twitter, GitHub: fnichol


#2

Awesome stuff!

My (quite basic) kitchen tests with kitchen-vagrant and the
vagrant-lxc provider are still running fine. Thanks for releasing this
with kitchen-vagrant 0.16.0 earlier this week!

“oooo, ahhhh” Windows?!

Indeed very useful (I might need to set up some windows boxes in the
near futur…)

So far I found the boxcutter/windows [0] boxes superb. Mischa Taylor
has done a great job with boxcutter. Not sure though whether they have
winrm enabled or not…

Btw: are there any real life test-kitchen / windows examples out there already?

Cheers,
Torben

[0] Github: https://github.com/boxcutter/windows

On Wed, Mar 25, 2015 at 4:27 PM, Fletcher Nichol fnichol@chef.io wrote:

Howdy y’alls!

—BEGIN tl;dr—

Guess what? We have a couple of pre-release gems cut today for Test Kitchen, specifically:

  • test-kitchen 1.4.0.beta.2 (beta.1 cut yesterday)
  • kitchen-vagrant 0.17.beta.2 (beta.1 cut yesterday)

Here’s my ask for anyone with time/interest/ability in the next day or 2:

Where ever you use Test Kitchen, give this pair of releases a try. If you don’t care about the Vagrant Driver, then just use the Test Kitchen pre-release. Use it exactly as you would any previous stable release, don’t change anything.

—END tl;dr—

It’s extremely important that this release doesn’t break existing projects, Drivers, and/or Provisioners in the wild. If you find issues, please let myself or Tyler Ball know and file an issue if you can. Linking to a reproducible project and kitchen diagnose —all output (scrubbed for credentials first) is such a big help, you have no idea.

Installing

If you have a Ruby workflow with RubyGems and/or Bundler this won’t be too much work:

Gem install with:

gem install test-kitchen —pre
gem install kitchen-vagrant —pre

Gemfile containing:

gem “test-kitchen”, “~> 1.4.0.beta.2”
gem “kitchen-vagrant”, “~> 0.17.0.beta.2”

If you’re using ChefDK, you might want to give this a spin to update test-kitchen (whipped up last night in a frenzy):

https://github.com/fnichol/chefdk-update-app/

To update the kitchen-vagrant gem, simply:

chef gem install kitchen-vagrant --pre --minimal-deps

Windows!

Note that this release has the much-fabled “Windows guest support” (insert “oooo, ahhhh” here). How do you get started? At the moment getting Vagrant base box images of Windows is still a big pain, but if you have access to one, here are the versions that should “just work”:

Windows with Kitchen::Vagrant

Any Vagrant base box should have vm.communicator = “winrm” and vm.guest = “windows” set by default, otherwise vagrant up will not be able to correctly boot the VM. Note that there are some Windows base boxes out there with vm.communicator = “ssh” set, so plan accordingly.

Assuming you have a Vagrant base box called “windows-2012r2”, you can use a .kitchen.yml similar to:


driver:
name: vagrant

platforms:

  • name: windows-2012r2

suites:

  • name: default

Note that with the updates in kitchen-vagrant you don’t need to set/override a :box, :box_url, :communicator, :guest, :port, :username, or :password. Sane defaults should apply.

For anyone who has tried the windows-guest-support branch, you may have seen extra transport configuration like this:


driver:
name: vagrant

platforms:

  • name: windows-2012r2
    transport:
    name: winrm

suites:

  • name: default

This is what Test Kitchen’s going to give you by default for any platform name starting with /^win/ (case insensitive) so add it, or don’t, it should work either way. If you don’t believe me, run kitchen diagnose against both and note the difference :slight_smile:

Finally, if you use certain Vagrant providers or use private networks in your setup, kitchen-vagrant is not currently able to determine your WinRM port. I’m hoping to fix this with a Vagrant plugin which kitchen-vagrant can use to return it’s WinRM and RDP hostname and port.

Further Reading

You can check out the CHANGELOG for more details/links regarding beta.1 and beta.2:

https://github.com/test-kitchen/test-kitchen/blob/master/CHANGELOG.md

Happy testing!


Fletcher Nichol
Engineering Lead - Test Driven Infrastructure
CHEF | http://www.chef.io
IRC, Twitter, GitHub: fnichol