vagrant-aws-mkubenka 0.7.2.pre.14 → 0.7.2.pre.16

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-1ee58c40e3f5/website/source/docs/provisioning/ansible_intro.html.md

@@ -0,0 +1,258 @@
+---
+layout: "docs"
+page_title: "Ansible - Short Introduction"
+sidebar_current: "provisioning-ansible-intro"
+description: |-
+  This page includes options and information that is applicable to both Vagrant
+  Ansible provisioners.
+---
+
+# Ansible and Vagrant
+
+The information below is applicable to both Vagrant Ansible provisioners:
+
+  - [`ansible`](/docs/provisioning/ansible.html), where Ansible is executed on the **Vagrant host**
+  - [`ansible_local`](/docs/provisioning/ansible_local.html), where Ansible is executed on the **Vagrant guest**
+
+The list of common options for these two provisioners is documented in a [separate documentation page](/docs/provisioning/ansible_common.html).
+
+This documentation page will not go into how to use Ansible or how to write Ansible playbooks, since Ansible is a complete deployment and configuration management system that is beyond the scope of Vagrant documentation.
+
+To learn more about Ansible, please consult the [Ansible Documentation Site](https://docs.ansible.com/).
+
+## The Playbook File
+
+The first component of a successful Ansible provisioner setup is the Ansible playbook which contains the steps that should be run on the guest. Ansible's
+[playbook documentation](https://docs.ansible.com/playbooks.html) goes into great detail on how to author playbooks, and there are a number of [best practices](https://docs.ansible.com/playbooks_best_practices.html) that can be applied to use Ansible's powerful features effectively.
+
+A playbook that installs and starts (or restarts) the NTP daemon via YUM looks like:
+
+```
+---
+- hosts: all
+  tasks:
+    - name: ensure ntpd is at the latest version
+      yum: pkg=ntp state=latest
+      notify:
+      - restart ntpd
+  handlers:
+    - name: restart ntpd
+      service: name=ntpd state=restarted
+```
+
+You can of course target other operating systems that do not have YUM by changing the playbook tasks. Ansible ships with a number of [modules](https://docs.ansible.com/modules.html) that make running otherwise tedious tasks dead simple.
+
+### Running Ansible
+
+The `playbook` option is strictly required by both Ansible provisioners ([`ansible`](/docs/provisioning/ansible.html) and [`ansible_local`](/docs/provisioning/ansible_local.html)), as illustrated in this basic Vagrantfile` configuration:
+
+```ruby
+Vagrant.configure("2") do |config|
+
+  # Use :ansible or :ansible_local to
+  # select the provisioner of your choice
+  config.vm.provision :ansible do |ansible|
+    ansible.playbook = "playbook.yml"
+  end
+end
+```
+
+Since an Ansible playbook can include many files, you may also collect the related files in a [directory structure](https://docs.ansible.com/playbooks_best_practices.html#directory-layout) like this:
+
+```
+.
+|-- Vagrantfile
+|-- provisioning
+|   |-- group_vars
+|           |-- all
+|   |-- roles
+|           |-- bar
+|           |-- foo
+|   |-- playbook.yml
+```
+
+In such an arrangement, the `ansible.playbook` path should be adjusted accordingly:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "ansible" do |ansible|
+    ansible.playbook = "provisioning/playbook.yml"
+  end
+end
+```
+
+## The Inventory File
+
+When using Ansible, it needs to know on which machines a given playbook should run. It does this by way of an [inventory](https://docs.ansible.com/intro_inventory.html) file which lists those machines. In the context of Vagrant, there are two ways to approach working with inventory files.
+
+### Auto-Generated Inventory
+
+The first and simplest option is to not provide one to Vagrant at all. Vagrant will generate an inventory file encompassing all of the virtual machines it manages, and use it for provisioning machines.
+
+#### Example with the [`ansible`](/docs/provisioning/ansible.html) provisioner
+
+```
+# Generated by Vagrant
+
+default ansible_ssh_host=127.0.0.1 ansible_ssh_port=2200 ansible_ssh_user='vagrant' ansible_ssh_private_key_file='/home/.../.vagrant/machines/default/virtualbox/private_key'
+```
+
+Note that the generated inventory file is stored as part of your local Vagrant environment in
+`.vagrant/provisioners/ansible/inventory/vagrant_ansible_inventory`.
+
+#### Example with the [`ansible_local`](/docs/provisioning/ansible_local.html) provisioner
+
+```
+# Generated by Vagrant
+
+default ansible_connection=local
+```
+
+Note that the generated inventory file is uploaded to the guest VM in a subdirectory of [`tmp_path`](/docs/provisioning/ansible_local.html), e.g. `/tmp/vagrant-ansible/inventory/vagrant_ansible_local_inventory`.
+
+#### Host Variables
+
+As of Vagrant 1.8.0, the [`host_vars`](/docs/provisioning/ansible_common.html#host_vars) option can be used to set [variables for individual hosts](https://docs.ansible.com/ansible/intro_inventory.html#host-variables) in the generated inventory file (see also the notes on group variables below).
+
+With this configuration example:
+
+```
+Vagrant.configure("2") do |config|
+  config.vm.define "host1"
+  config.vm.define "host2"
+  config.vm.provision "ansible" do |ansible|
+    ansible.playbook = "playbook.yml"
+    ansible.host_vars = {
+      "host1" => {"http_port" => 80,
+                  "maxRequestsPerChild" => 808},
+      "host2" => {"http_port" => 303,
+                  "maxRequestsPerChild" => 909}
+    }
+  end
+end
+```
+
+Vagrant would generate the following inventory file:
+
+```
+# Generated by Vagrant
+
+host1 ansible_ssh_host=... http_port=80 maxRequestsPerChild=808
+host2 ansible_ssh_host=... http_port=303 maxRequestsPerChild=909
+```
+
+#### Groups and Group Variables
+
+The [`groups`](/docs/provisioning/ansible_common.html#groups) option can be used to pass a hash of group names and group members to be included in the generated inventory file.
+
+As of Vagrant 1.8.0, it is also possible to specify [group variables](https://docs.ansible.com/ansible/intro_inventory.html#group-variables), and group members as [host ranges (with numeric or alphabetic patterns)](https://docs.ansible.com/ansible/intro_inventory.html#hosts-and-groups).
+
+With this configuration example:
+
+```
+Vagrant.configure("2") do |config|
+
+  config.vm.box = "ubuntu/trusty64"
+
+  config.vm.define "machine1"
+  config.vm.define "machine2"
+
+  config.vm.provision "ansible" do |ansible|
+    ansible.playbook = "playbook.yml"
+    ansible.groups = {
+      "group1" => ["machine1"],
+      "group2" => ["machine2"],
+      "group3" => ["machine[1:2]"],
+      "group4" => ["other_node-[a:d]"], # silly group definition
+      "all_groups:children" => ["group1", "group2"],
+      "group1:vars" => {"variable1" => 9,
+                        "variable2" => "example"}
+    }
+  end
+end
+```
+
+Vagrant would generate the following inventory file:
+
+```
+# Generated by Vagrant
+
+machine1 ansible_ssh_host=127.0.0.1 ansible_ssh_port=2200 ansible_ssh_user='vagrant' ansible_ssh_private_key_file='/home/.../.vagrant/machines/machine1/virtualbox/private_key'
+machine2 ansible_ssh_host=127.0.0.1 ansible_ssh_port=2222 ansible_ssh_user='vagrant' ansible_ssh_private_key_file='/home/.../.vagrant/machines/machine2/virtualbox/private_key'
+
+[group1]
+machine1
+
+[group2]
+machine2
+
+[group3]
+machine[1:2]
+
+[group4]
+other_node-[a:d]
+
+[all_groups:children]
+group1
+group2
+
+[group1:vars]
+variable1=9
+variable2=example
+```
+
+**Notes:**
+
+  - Prior to Vagrant 1.7.3, the `ansible_ssh_private_key_file` variable was not set in generated inventory, but passed as command line argument to `ansible-playbook` command.
+  - The generation of group variables blocks (e.g. `[group1:vars]`) is only possible since Vagrant 1.8.0. Note however that setting variables directly in the inventory is not the [preferred practice in Ansible](https://docs.ansible.com/intro_inventory.html#splitting-out-host-and-group-specific-data). If possible, group (or host) variables should be set in `YAML` files stored in the `group_vars/` or `host_vars/` directories in the playbook (or inventory) directory instead.
+  - Unmanaged machines and undefined groups are not added to the inventory, to avoid useless Ansible errors (e.g. *unreachable host* or *undefined child group*)
+
+    For example, `machine3` and `group3` in the example below would not be added to the generated inventory file:
+
+    ```ruby
+    ansible.groups = {
+      "group1" => ["machine1"],
+      "group2" => ["machine2", "machine3"],
+      "all_groups:children" => ["group1", "group2", "group3"]
+    }
+    ```
+  - [Host range patterns (numeric and alphabetic ranges)](https://docs.ansible.com/ansible/intro_inventory.html#hosts-and-groups) will not be validated by Vagrant. As of Vagrant 1.8.0, host range patterns will be added as group members to the inventory anyway, this might lead to errors in Ansible (e.g *unreachable host*).
+
+### Static Inventory
+
+The second option is for situations where you would like to have more control over the inventory management.
+
+With the [`inventory_path`](/docs/provisioning/ansible_common.html#inventory_path) option, you can reference a specific inventory resource (e.g. a static inventory file, a [dynamic inventory script](https://docs.ansible.com/intro_dynamic_inventory.html) or even [multiple inventories stored in the same directory](https://docs.ansible.com/intro_dynamic_inventory.html#using-multiple-inventory-sources)). Vagrant will then use this inventory information instead of generating it.
+
+A very simple inventory file for use with Vagrant might look like:
+
+```
+default ansible_ssh_host=192.168.111.222
+```
+
+Where the above IP address is one set in your Vagrantfile:
+
+```
+config.vm.network :private_network, ip: "192.168.111.222"
+```
+
+**Notes:**
+
+  - The machine names in `Vagrantfile` and `ansible.inventory_path` files should correspond, unless you use `ansible.limit` option to reference the correct machines.
+  - The SSH host addresses (and ports) must obviously be specified twice, in `Vagrantfile` and `ansible.inventory_path` files.
+  - Sharing hostnames across Vagrant host and guests might be a good idea (e.g. with some Ansible configuration task, or with a plugin like [`vagrant-hostmanager`](https://github.com/smdahlen/vagrant-hostmanager)).
+
+### The Ansible Configuration File
+
+Certain settings in Ansible are (only) adjustable via a [configuration file](https://docs.ansible.com/intro_configuration.html), and you might want to ship such a file in your Vagrant project.
+
+When shipping an Ansible configuration file it is good to know that:
+
+  - as of Ansible 1.5, the lookup order is the following:
+    - any path set as `ANSIBLE_CONFIG` environment variable
+    - `ansible.cfg` in the runtime working directory
+    - `.ansible.cfg` in the user home directory
+    - `/etc/ansible/ansible.cfg`
+  - Ansible commands don't look for a configuration file relative to the playbook file location (e.g. in the same directory)
+  - an `ansible.cfg` file located in the same directory as your `Vagrantfile` will be used by default.
+  - it is also possible to reference any other location with the [config_file](/docs/provisioning/ansible_common.html#config_file) provisioner option. In this case, Vagrant will set the `ANSIBLE_CONFIG` environment variable accordingly.

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-1ee58c40e3f5/website/source/docs/provisioning/ansible_local.html.md

@@ -0,0 +1,197 @@
+---
+layout: "docs"
+page_title: "Ansible Local - Provisioning"
+sidebar_current: "provisioning-ansible-local"
+description: |-
+  The Vagrant Ansible Local provisioner allows you to provision the guest using Ansible playbooks by executing "ansible-playbook" directly on the guest
+  machine.
+---
+
+# Ansible Local Provisioner
+
+**Provisioner name: `ansible_local`**
+
+The Vagrant Ansible Local provisioner allows you to provision the guest using [Ansible](http://ansible.com) playbooks by executing **`ansible-playbook` directly on the guest machine**.
+
+<div class="alert alert-warning">
+  <strong>Warning:</strong>
+  If you are not familiar with Ansible and Vagrant already, I recommend starting with the <a href="/docs/provisioning/shell.html">shell provisioner</a>. However, if you are comfortable with Vagrant already, Vagrant is a great way to learn Ansible.
+</div>
+
+## Setup Requirements
+
+The main advantage of the Ansible Local provisioner in comparison to the [Ansible (remote) provisioner](/docs/provisioning/ansible.html) is that it does not require any additional software on your Vagrant host.
+
+On the other hand, [Ansible must obviously be installed](https://docs.ansible.com/intro_installation.html#installing-the-control-machine) on your guest machine(s).
+
+**Note:** By default, Vagrant will *try* to automatically install Ansible if it is not yet present on the guest machine (see the `install` option below for more details).
+
+## Usage
+
+This page only documents the specific parts of the `ansible_local` provisioner. General Ansible concepts like Playbook or Inventory are shortly explained in the [introduction to Ansible and Vagrant](/docs/provisioning/ansible_intro.html).
+
+The Ansible Local provisioner requires that all the Ansible Playbook files are available on the guest machine, at the location referred by the `provisioning_path` option. Usually these files are initially present on the host machine (as part of your Vagrant project), and it is quite easy to share them with a Vagrant [Synced Folder](/docs/synced-folders/).
+
+### Simplest Configuration
+
+To run Ansible from your Vagrant guest, the basic `Vagrantfile` configuration looks like:
+
+```ruby
+Vagrant.configure("2") do |config|
+  # Run Ansible from the Vagrant VM
+  config.vm.provision "ansible_local" do |ansible|
+    ansible.playbook = "playbook.yml"
+  end
+end
+```
+
+**Requirements:**
+
+  - The `playbook.yml` file is stored in your Vagrant's project home directory.
+
+  - The [default shared directory](/docs/synced-folders/basic_usage.html) is enabled (`.` &rarr; `/vagrant`).
+
+## Options
+
+This section lists the _specific_ options for the Ansible Local provisioner. In addition to the options listed below, this provisioner supports the [**common options** for both Ansible provisioners](/docs/provisioning/ansible_common.html).
+
+- `install` (boolean) - Try to automatically install Ansible on the guest system.
+
+    This option is enabled by default.
+
+    Vagrant will try to install (or upgrade) Ansible when one of these conditions are met:
+
+    - Ansible is not installed (or cannot be found).
+    - The [`version`](/docs/provisioning/ansible_common.html#version) option is set to `"latest"`.
+    - The current Ansible version does not correspond to the [`version`](/docs/provisioning/ansible_common.html#version) option.
+
+    <div class="alert alert-warning">
+      <strong>Attention:</strong>
+      There is no guarantee that this automated installation will replace a custom Ansible setup, that might be already present on the Vagrant box.
+    </div>
+
+- `install_mode` (`:default`, `:pip`, or `:pip_args_only`) - Select the way to automatically install Ansible on the guest system.
+
+  - `:default`: Ansible is installed from the operating system package manager. This mode doesn't support `version` selection. For many platforms (e.g Debian, FreeBSD, OpenSUSE) the official package repository is used, except for the following Linux distributions:
+      - On Ubuntu-like systems, the latest Ansible release is installed from the `ppa:ansible/ansible` repository.
+      - On RedHat-like systems, the latest Ansible release is installed from the [EPEL](http://fedoraproject.org/wiki/EPEL) repository.
+
+  - `:pip`: Ansible is installed from [PyPI](https://pypi.python.org/pypi) with [pip](https://pip.pypa.io) package installer. With this mode, Vagrant will systematically try to [install the latest pip version](https://pip.pypa.io/en/stable/installing/#installing-with-get-pip-py). With the `:pip` mode you can optionally install a specific Ansible release by setting the [`version`](/docs/provisioning/ansible_common.html#version) option.
+
+        Example:
+
+        ```ruby
+        config.vm.provision "ansible_local" do |ansible|
+          ansible.playbook = "playbook.yml"
+          ansible.install_mode = "pip"
+          ansible.version = "2.2.1.0"
+        end
+        ```
+        With this configuration, Vagrant will install `pip` and then execute the command
+
+        ```shell
+        sudo pip install --upgrade ansible==2.2.1.0
+        ```
+
+  - `:pip_args_only`: This mode is very similar to the `:pip` mode, with the difference that in this case no pip arguments will be automatically set by Vagrant.
+
+        Example:
+
+        ```ruby
+        config.vm.provision "ansible_local" do |ansible|
+          ansible.playbook = "playbook.yml"
+          ansible.install_mode = "pip_args_only"
+          ansible.pip_args = "-r /vagrant/requirements.txt"
+        end
+        ```
+
+        With this configuration, Vagrant will install `pip` and then execute the command
+
+        ```shell
+        sudo pip install -r /vagrant/requirements.txt
+        ```
+
+    The default value of `install_mode` is `:default`, and any invalid value for this option will silently fall back to the default value.
+
+- `pip_args` (string) - When Ansible is installed via pip, this option allows the definition of additional pip arguments to be passed along on the command line (for example, [`--index-url`](https://pip.pypa.io/en/stable/reference/pip_install/#cmdoption-i)).
+
+    By default, this option is not set.
+
+    Example:
+
+    ```ruby
+    config.vm.provision "ansible_local" do |ansible|
+      ansible.playbook = "playbook.yml"
+      ansible.install_mode = :pip
+      ansible.pip_args = "--install-url https://pypi.internal"
+    end
+    ```
+
+    With this configuration, Vagrant will install `pip` and then execute the command
+
+    ```shell
+    sudo pip install --index-url https://pypi.internal --upgrade ansible
+    ```
+
+- `provisioning_path` (string) - An absolute path on the guest machine where the Ansible files are stored. The `ansible-galaxy` and `ansible-playbook` commands are executed from this directory. This is the location to place an [ansible.cfg](http://docs.ansible.com/ansible/intro_configuration.html) file, in case you need it.
+
+    The default value is `/vagrant`.
+
+- `tmp_path` (string) - An absolute path on the guest machine where temporary files are stored by the Ansible Local provisioner.
+
+    The default value is `/tmp/vagrant-ansible`
+
+## Tips and Tricks
+
+### Ansible Parallel Execution from a Guest
+
+With the following configuration pattern, you can install and execute Ansible only on a single guest machine (the `"controller"`) to provision all your machines.
+
+```ruby
+Vagrant.configure("2") do |config|
+
+  config.vm.box = "ubuntu/trusty64"
+
+  config.vm.define "node1" do |machine|
+    machine.vm.network "private_network", ip: "172.17.177.21"
+  end
+
+  config.vm.define "node2" do |machine|
+    machine.vm.network "private_network", ip: "172.17.177.22"
+  end
+
+  config.vm.define 'controller' do |machine|
+    machine.vm.network "private_network", ip: "172.17.177.11"
+
+    machine.vm.provision :ansible_local do |ansible|
+      ansible.playbook       = "example.yml"
+      ansible.verbose        = true
+      ansible.install        = true
+      ansible.limit          = "all" # or only "nodes" group, etc.
+      ansible.inventory_path = "inventory"
+    end
+  end
+
+end
+```
+
+You need to create a static `inventory` file that corresponds to your `Vagrantfile` machine definitions:
+
+```
+controller ansible_connection=local
+node1      ansible_ssh_host=172.17.177.21 ansible_ssh_private_key_file=/vagrant/.vagrant/machines/node1/virtualbox/private_key
+node2      ansible_ssh_host=172.17.177.22 ansible_ssh_private_key_file=/vagrant/.vagrant/machines/node2/virtualbox/private_key
+
+[nodes]
+node[1:2]
+```
+
+And finally, you also have to create an [`ansible.cfg` file](https://docs.ansible.com/intro_configuration.html#openssh-specific-settings) to fully disable SSH host key checking. More SSH configurations can be added to the `ssh_args` parameter (e.g. agent forwarding, etc.)
+
+```
+[defaults]
+host_key_checking = no
+
+[ssh_connection]
+ssh_args = -o ControlMaster=auto -o ControlPersist=60s -o UserKnownHostsFile=/dev/null -o IdentitiesOnly=yes
+```

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-1ee58c40e3f5/website/source/docs/provisioning/chef_common.html.md

@@ -0,0 +1,136 @@
+---
+layout: "docs"
+page_title: "Common Chef Options - Provisioning"
+sidebar_current: "provisioning-chefcommon"
+description: |-
+  The following options are available to all Vagrant Chef provisioners. Many of
+  these options are for advanced users only and should not be used unless you
+  understand their purpose.
+---
+
+# Shared Chef Options
+
+## All Chef Provisioners
+
+The following options are available to all Vagrant Chef provisioners. Many of
+these options are for advanced users only and should not be used unless you
+understand their purpose.
+
+- `binary_path` (string) - The path to Chef's `bin/` directory on the guest
+  machine.
+
+- `binary_env` (string) - Arbitrary environment variables to set before running
+  the Chef provisioner command. This should be of the format `KEY=value` as a
+  string.
+
+- `install` (boolean, string) - Install Chef on the system if it does not exist.
+  The default value is "true", which will use the official Omnibus installer
+  from Chef. This is a trinary attribute (it can have three values):
+
+    - `true` (boolean) - install Chef
+    - `false` (boolean) - do not install Chef
+    - `"force"` (string) - install Chef, even if it is already installed at the
+      proper version on the guest
+
+- `installer_download_path` (string) - The path where the Chef installer will be
+  downloaded to. This option is only honored if the `install` attribute is
+  `true` or `"force"`. The default value is to use the path provided by Chef's
+  Omnibus installer, which varies between releases. This value has no effect on
+  Windows because Chef's omnibus installer lacks the option on Windows.
+
+- `log_level` (string) - The Chef log level. See the Chef docs for acceptable
+  values.
+
+- `product` (string) - The name of the Chef product to install. The default
+  value is "chef", which corresponds to the Chef Client. You can also specify
+  "chefdk", which will install the Chef Development Kit. At the time of this
+  writing, the ChefDK is only available through the "current" channel, so you
+  will need to update that value as well.
+
+- `channel` (string) - The release channel from which to pull the Chef Client
+  or the Chef Development Kit. The default value is `"stable"` which will pull
+  the latest stable version of the Chef Client. For newer versions, or if you
+  wish to install the Chef Development Kit, you may need to change the channel
+  to "current". Because Chef Software floats the versions that are contained in
+  the channel, they may change and Vagrant is unable to detect this.
+
+- `version` (string) - The version of Chef to install on the guest. If Chef is
+  already installed on the system, the installed version is compared with the
+  requested version. If they match, no action is taken. If they do not match,
+  the value specified in this attribute will be installed in favor of the
+  existing version (a message will be displayed).
+  You can also specify "latest" (default), which will install the latest
+  version of Chef on the system. In this case, Chef will use whatever
+  version is on the system. To force the newest version of Chef to be
+  installed on every provision, set the [`install`](#install) option to "force".
+
+- `omnibus_url` (string) - Location of Omnibus installation scripts.
+  This URL specifies the location of install.sh/install.ps1 for
+  Linux/Unix and Windows respectively.
+  It defaults to https://omnitruck.chef.io. The full URL is in this case:
+
+   - Linux/Unix: https://omnitruck.chef.io/install.sh
+   - Windows: https://omnitruck.chef.io/install.ps1
+
+  If you want to have https://example.com/install.sh as Omnibus script
+  for your Linux/Unix installations, you should set this option to
+  https://example.com
+
+## Runner Chef Provisioners
+
+The following options are available to any of the Chef "runner" provisioners
+which include [Chef Solo](/docs/provisioning/chef_solo.html), [Chef Zero](/docs/provisioning/chef_zero.html), and [Chef Client](/docs/provisioning/chef_client.html).
+
+* `arguments` (string) - A list of additional arguments to pass on the
+  command-line to Chef. Since these are passed in a shell-like environment,
+  be sure to properly quote and escape characters if necessary. By default,
+  no additional arguments are sent.
+
+* `attempts` (int) - The number of times Chef will be run if an error occurs.
+  This defaults to 1. This can be increased to a higher number if your Chef
+  runs take multiple runs to reach convergence.
+
+* `custom_config_path` (string) - A path to a custom Chef configuration local
+  on your machine that will be used as the Chef configuration. This Chef
+  configuration will be loaded _after_ the Chef configuration that Vagrant
+  generates, allowing you to override anything that Vagrant does. This is
+  also a great way to use new Chef features that may not be supported fully
+  by Vagrant's abstractions yet.
+
+* `encrypted_data_bag_secret_key_path` (string) - The path to the secret key
+  file to decrypt encrypted data bags. By default, this is not set.
+
+* `environment` (string) - The environment you want the Chef run to be
+  a part of.
+
+* `formatter` (string) - The formatter to use for output from Chef.
+
+* `http_proxy`, `http_proxy_user`, `http_proxy_pass`, `no_proxy` (string) - Settings
+  to configure HTTP and HTTPS proxies to use from Chef. These settings are
+  also available with `http` replaced with `https` to configure HTTPS proxies.
+
+* `json` (hash) - Custom node attributes to pass into the Chef run.
+
+* `log_level` (string) - The log level for Chef output. This defaults to
+  "info".
+
+* `node_name` (string) - The node name for the Chef Client. By default this
+  will be your hostname.
+
+* `provisioning_path` (string) - The path on the remote machine where Vagrant
+  will store all necessary files for provisioning such as cookbooks, configurations,
+  etc. This path must be world writable. By default this is
+  `/tmp/vagrant-chef-#` where "#" is replaced by a unique counter.
+
+* `run_list` (array) - The run list that will be executed on the node.
+
+* `file_cache_path` and `file_backup_path` (string) - Paths on the remote
+  machine where files will be cached and backed up. It is useful sometimes
+  to configure this to a synced folder address so that this can be shared
+  across many Vagrant runs.
+
+* `verbose_logging` (boolean) - Whether or not to enable the Chef
+  `verbose_logging` option. By default this is false.
+
+* `enable_reporting` (boolean) - Whether or not to enable the Chef
+  `enable_reporting` option. By default this is true.