These are frequently asked questions or tips that don't have a better home just yet.
First, you need to make sure the driver exists, if it does:
~$ gem install kitchen-openstack # for instance ~$ vi cookbooks/demo/.kitchen.yml # wherever your .kitchen.yml is for your cookbook
.kitchen.yml as appropriate and run
kitchen list to verify that everything
is working as expected. There is a strong chance that the flavors, or
image names are different per driver, so when migrating between drivers be prepared
to change these at the very least.
Although there is no strict configuration supporting this, a convention has emerged among the
community that for public cookbooks the default
.kitchen.yml remains vagrant and any additional drivers get their own configuration file in the form of
These are meant to be used in place
.kitchen.yml via the environment variable
Note that it is
$ KITCHEN_YAML=.kitchen.ec2.yml kitchen list OR $ export KITCHEN_YAML=.kitchen.ec2.yml $ kitchen list
Certain drivers, like
kitchen-dokken recommend setting
KITCHEN_LOCAL_YAML environment variable to ensure these configs are used when there are multiple in a directory.
To borrow from this discourse post, one can:
chef gem install appbundle-updater appbundle-updater chefdk test-kitchen v1.6.0 # or whatever version you want update to
The appbundle-updater gem can update an "appbundled" gem in a chef or chefdk omnibus install and reference a specific git branch, tag or sha. The above uses it to pull down the v1.6.0 tag of the test-kitchen repo and then properly pins that inside an existing ChefDK installation.
transport section in
.kitchen.yml, for instance:
transport: username: ubuntu
So there are a few things that already exist that sort of cover this in the kitchen world:
For the system level proxies and the polipo/squid locally you don't need to do much but you'll still need to edit the conf files for yum/apt as appropriate. If vagrant-cachier it will be used by
kitchen-vagrant as default. This behaviour is documented here.