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

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-5333e60e2d38/website/source/docs/other/atlas.html.md

@@ -1,23 +0,0 @@
----
-layout: "docs"
-page_title: "Atlas and Vagrant"
-sidebar_current: "other-atlas"
-description: |-
-  A brief description of how to use, sign up for and access the
-  Vagrant features in Atlas.
----
-
-# Atlas and Vagrant
-
-Atlas is the HashiCorp Suite for the Enterprise,
-but also provides features for the community. It hosts
-a <a href="https://atlas.hashicorp.com/boxes/search">public registry of Vagrant boxes</a>
-as well as powers the Vagrant share features.
-
-Vagrant Enterprise is provided via Atlas and allows
-for private boxes to be hosted and distributed to
-your team.
-
-## Signing up for Atlas
-
-You can signup for a free Atlas account <a href="https://atlas.hashicorp.com/account/new">here</a>.

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-5333e60e2d38/website/source/docs/other/environmental-variables.html.md

@@ -1,173 +0,0 @@
----
-layout: "docs"
-page_title: "Environmental Variables"
-sidebar_current: "other-envvars"
-description: |-
-  Vagrant has a set of environmental variables that can be used to
-  configure and control it in a global way. This page lists those environmental
-  variables.
----
-
-# Environmental Variables
-
-Vagrant has a set of environmental variables that can be used to
-configure and control it in a global way. This page lists those environmental
-variables.
-
-## `VAGRANT_DEBUG_LAUNCHER`
-
-For performance reasons, especially for Windows users, Vagrant uses a static
-binary to launch the actual Vagrant process. If you have _very_ early issues
-when launching Vagrant from the official installer, you can specify the
-`VAGRANT_DEBUG_LAUNCHER` environment variable to output debugging information
-about the launch process.
-
-## `VAGRANT_DEFAULT_PROVIDER`
-
-This configures the default provider Vagrant will use.
-
-This normally does not need to be set since Vagrant is fairly intelligent
-about how to detect the default provider. By setting this, you will force
-Vagrant to use this provider for any _new_ Vagrant environments. Existing
-Vagrant environments will continue to use the provider they came `up` with.
-Once you `vagrant destroy` existing environments, this will take effect.
-
-## `VAGRANT_BOX_UPDATE_CHECK_DISABLE`
-
-By default, Vagrant will query the metadata API server to see if a newer
-box version is available for download. This optional can be disabled on a
-per-Vagrantfile basis with `config.vm.box_check_update`, but it can also be
-disabled globally setting `VAGRANT_BOX_UPDATE_CHECK_DISABLE` to any non-empty
-value.
-
-This option will not affect global box functions like `vagrant box update`.
-
-## `VAGRANT_CHECKPOINT_DISABLE`
-
-Vagrant does occasional network calls to check whether the version of Vagrant
-that is running locally is up to date. We understand that software making remote
-calls over the internet for any reason can be undesirable. To surpress these
-calls, set the environment variable `VAGRANT_CHECKPOINT_DISABLE` to any
-non-empty value.
-
-If you use other HashiCorp tools like Packer and would prefer to configure this
-setting only once, you can set `CHECKPOINT_DISABLE` instead.
-
-## `VAGRANT_CWD`
-
-`VAGRANT_CWD` can be set to change the working directory of Vagrant. By
-default, Vagrant uses the current directory you are in. The working directory
-is important because it is where Vagrant looks for the Vagrantfile. It
-also defines how relative paths in the Vagrantfile are expanded, since they're
-expanded relative to where the Vagrantfile is found.
-
-This environmental variable is most commonly set when running Vagrant from
-a scripting environment in order to set the directory that Vagrant sees.
-
-## `VAGRANT_DOTFILE_PATH`
-
-`VAGRANT_DOTFILE_PATH` can be set to change the directory where Vagrant stores
-VM-specific state, such as the VirtualBox VM UUID. By default, this is set to
-`.vagrant`. If you keep your Vagrantfile in a Dropbox folder in order to share
-the folder between your desktop and laptop (for example), Vagrant will overwrite
-the files in this directory with the details of the VM on the most recently-used
-host. To avoid this, you could set `VAGRANT_DOTFILE_PATH` to `.vagrant-laptop`
-and `.vagrant-desktop` on the respective machines. (Remember to update your
-`.gitignore`!)
-
-## `VAGRANT_HOME`
-
-`VAGRANT_HOME` can be set to change the directory where Vagrant stores
-global state. By default, this is set to `~/.vagrant.d`. The Vagrant home
-directory is where things such as boxes are stored, so it can actually become
-quite large on disk.
-
-## `VAGRANT_LOG`
-
-`VAGRANT_LOG` specifies the verbosity of log messages from Vagrant.
-By default, Vagrant does not actively show any log messages.
-
-Log messages are very useful when troubleshooting issues, reporting
-bugs, or getting support. At the most verbose level, Vagrant outputs
-basically everything it is doing.
-
-Available log levels are "debug," "info," "warn," and "error." Both
-"warn" and "error" are practically useless since there are very few
-cases of these, and Vagrant generally reports them within the normal
-output.
-
-"info" is a good level to start with if you are having problems, because
-while it is much louder than normal output, it is still very human-readable
-and can help identify certain issues.
-
-"debug" output is _extremely_ verbose and can be difficult to read without
-some knowledge of Vagrant internals. It is the best output to attach to
-a support request or bug report, however.
-
-## `VAGRANT_NO_COLOR`
-
-If this is set to any value, then Vagrant will not use any colorized
-output. This is useful if you are logging the output to a file or
-on a system that does not support colors.
-
-The equivalent behavior can be achieved by using the `--no-color` flag
-on a command-by-command basis. This environmental variable is useful
-for setting this flag globally.
-
-## `VAGRANT_FORCE_COLOR`
-
-If this is set to any value, then Vagrant will force colored output, even
-if it detected that there is no TTY or the current environment does not
-support it.
-
-The equivalent behavior can be achieved by using the `--color` flag on a
-command-by-command basis. This environmental variable is useful for setting
-this flag globally.
-
-## `VAGRANT_NO_PLUGINS`
-
-If this is set to any value, then Vagrant will not load any 3rd party
-plugins. This is useful if you install a plugin and it is introducing
-instability to Vagrant, or if you want a specific Vagrant environment to
-not load plugins.
-
-Note that any `vagrant plugin` commands automatically do not load any
-plugins, so if you do install any unstable plugins, you can always use
-the `vagrant plugin` commands without having to worry.
-
-## `VAGRANT_ALLOW_PLUGIN_SOURCE_ERRORS`
-
-If this is set to any value, then Vagrant will not error when a configured
-plugin source is unavailable. When installing a Vagrant plugin Vagrant
-will error and halt if a plugin source is inaccessible. In some cases it
-may be desirable to ignore inaccessible sources and continue with the
-plugin installation. Enabling this value will cause Vagrant to simply log
-the plugin source error and continue.
-
-## `VAGRANT_NO_PARALLEL`
-
-If this is set, Vagrant will not perform any parallel operations (such as
-parallel box provisioning). All operations will be performed in serial.
-
-## `VAGRANT_SKIP_SUBPROCESS_JAILBREAK`
-
-As of Vagrant 1.7.3, Vagrant tries to intelligently detect if it is running in
-the installer or running via Bundler. Although not officially supported, Vagrant
-tries its best to work when executed via Bundler. When Vagrant detects that you
-have spawned a subprocess that lives outside of Vagrant's installer, Vagrant
-will do its best to reset the preserved environment dring the subprocess
-execution.
-
-If Vagrant detects it is running outside of the officially installer, the
-original environment will always be restored. You can disable this automatic
-jailbreak by setting `VAGRANT_SKIP_SUBPROCESS_JAILBREAK`.
-
-## `VAGRANT_VAGRANTFILE`
-
-This specifies the filename of the Vagrantfile that Vagrant searches for.
-By default, this is "Vagrantfile". Note that this is _not_ a file path,
-but just a filename.
-
-This environmental variable is commonly used in scripting environments
-where a single folder may contain multiple Vagrantfiles representing
-different configurations.

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-5333e60e2d38/website/source/docs/other/index.html.md

@@ -1,17 +0,0 @@
----
-layout: "docs"
-page_title: "Other"
-sidebar_current: "other"
-description: |-
-  This page covers Vagrant information that does not quite fit under the other
-  categories.
----
-
-# Other
-
-This section covers other information that does not quite fit under the
-other categories.
-
-- [Atlas](/docs/other/atlas.html)
-- [Debugging](/docs/other/debugging.html)
-- [Environment Variables](/docs/other/environmental-variables.html)

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-5333e60e2d38/website/source/docs/other/wsl.html.md

@@ -1,111 +0,0 @@
----
-layout: "docs"
-page_title: "Vagrant and Windows Subsystem for Linux"
-sidebar_current: "other-wsl"
-description: |-
-  An overview of using Vagrant on Windows within the Windows Subsystem
-  for Linux.
----
-
-# Vagrant and Windows Subsystem for Linux
-
-Windows has recently introduced a new feature called the Windows Subsystem
-for Linux (WSL). This is a beta feature available in developer mode on recent
-releases of Windows 10. It is important to note that this feature is still
-in _beta_ on Windows, and Vagrant support should be considered _alpha_.
-
-<div class="alert alert-warning">
-  <strong>Warning: Advanced Topic!</strong> Using Vagrant within the Windows
-  Subsystem for Linux is an advanced topic that only experienced Vagrant users
-  who are reasonably comfortable with Windows, WSL, and Linux should approach.
-</div>
-
-
-# Installation
-
-Installation requires WSL, Ubuntu on Windows, and Vagrant. Read on for installation
-instructions for each item.
-
-## Windows Subsystem for Linux and Ubuntu on Windows
-
-First install the Windows Subsystem for Linux, followed by Ubuntu on Windows. This guide
-from Microsoft walks through the process:
-
-* https://msdn.microsoft.com/en-us/commandline/wsl/install_guide
-
-## Vagrant Installation
-
-Vagrant _must_ be installed within Ubuntu on Windows. Even though the `vagrant.exe`
-file can be executed from within the WSL, it will not function as expected. To
-install Vagrant into the WSL, follow these steps:
-
-* Download the 64-bit Debian package from the downloads page.
-* Open a `cmd` or `powershell` window
-* Enter the command: `bash`
-* Install vagrant: `sudo dpkg -i vagrant_VERSION_x86_64.deb`
-
-```
-C:\Users\vagrant> bash
-vagrant@vagrant-10:/mnt/c/Users/vagrant$ sudo dpkg -i vagrant_VERSION_x86_64.deb
-[sudo] password for vagrant:
-(Reading database ... 31885 files and directories currently installed.)
-Preparing to unpack vagrant_VERSION_x86_64.deb ...
-Unpacking vagrant (1:VERSION) ...
-Setting up vagrant (1:VERSION) ...
-vagrant@vagrant-10:/mnt/c/Users/vagrant$ vagrant help
-Usage: vagrant [options] <command> [<args>]
-```
-
-# Vagrant Usage
-
-Vagrant will detect when it is being run within the WSL and adjust how it
-locates and executes third party executables. For example, when using the
-VirtualBox provider Vagrant will interact with VirtualBox installed on
-the Windows system, not within the WSL. It is important to ensure that
-any required Windows executable is available within your `PATH` to allow
-Vagrant to access them.
-
-## Windows Access
-
-Working within the WSL provides a layer of isolation from the actual
-Windows system. In most cases Vagrant will need access to the actual
-Windows system to function correctly. As most Vagrant providers will
-need to be installed on Windows directly (not within the WSL) Vagrant
-will require Windows access. Access to the Windows system is controlled
-via an environment variable: `VAGRANT_WSL_ENABLE_WINDOWS_ACCESS`. If
-this environment variable is set, Vagrant will access the Windows system
-to run executables and enable things like synced folders. When running
-in a bash shell within WSL, the environment variable can be setup like so:
-
-```
-$ export VAGRANT_WSL_ENABLE_WINDOWS_ACCESS="1"
-```
-
-This will enable Vagrant to access the Windows system outside of the
-WSL and properly interact with Windows executables. This will automatically
-modify the `VAGRANT_HOME` environment variable if it is not already defined,
-setting it to be within the user's home directory on Windows.
-
-It is important to note that paths shared with the Windows system will
-not have Linux permissions enforced. For example, when a directory within
-the WSL is synced to a guest using the VirtualBox provider, any local
-permissions defined on that directory (or its contents) will not be
-visible from the guest. Likewise, any files created from the guest within
-the synced folder will be world readable/writeable in WSL.
-
-Other useful WSL related environment variables:
-
-* `VAGRANT_WSL_WINDOWS_ACCESS_USER` - Override current Windows username
-* `VAGRANT_WSL_DISABLE_VAGRANT_HOME` - Do not modify the `VAGRANT_HOME` variable
-* `VAGRANT_WSL_WINDOWS_ACCESS_USER_HOME_PATH` - Custom Windows system home path
-
-## Using Docker
-
-The docker daemon cannot be run inside the Windows Subsystem for Linux. However,
-the daemon _can_ be run on Windows and accessed by Vagrant while running in the
-WSL. Once docker is installed and running on Windows, export the following
-environment variable to give Vagrant access:
-
-```
-$ vagrant@vagrant-10:/mnt/c/Users/vagrant$ export DOCKER_HOST=tcp://127.0.0.1:2375
-```

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-5333e60e2d38/website/source/docs/provisioning/ansible.html.md

@@ -1,142 +0,0 @@
----
-layout: "docs"
-page_title: "Ansible - Provisioning"
-sidebar_current: "provisioning-ansible"
-description: |-
-  The Vagrant Ansible provisioner allows you to provision the guest using
-  Ansible playbooks by executing "ansible-playbook" from the Vagrant host.
----
-
-# Ansible Provisioner
-
-**Provisioner name: `ansible`**
-
-The Vagrant Ansible provisioner allows you to provision the guest using [Ansible](http://ansible.com) playbooks by executing **`ansible-playbook` from the Vagrant host**.
-
-<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
-
-  - **[Install Ansible](https://docs.ansible.com/intro_installation.html#installing-the-control-machine) on your Vagrant host**.
-
-  - Your Vagrant host should ideally provide a recent version of OpenSSH that [supports ControlPersist](https://docs.ansible.com/faq.html#how-do-i-get-ansible-to-reuse-connections-enable-kerberized-ssh-or-have-ansible-pay-attention-to-my-local-ssh-config-file).
-
-If installing Ansible directly on the Vagrant host is not an option in your development environment, you might be looking for the <a href="/docs/provisioning/ansible_local.html">Ansible Local provisioner</a> alternative.
-
-## Usage
-
-This page only documents the specific parts of the `ansible` (remote) provisioner. General Ansible concepts like Playbook or Inventory are shortly explained in the [introduction to Ansible and Vagrant](/docs/provisioning/ansible_intro.html).
-
-### Simplest Configuration
-
-To run Ansible against your Vagrant guest, the basic `Vagrantfile` configuration looks like:
-
-```ruby
-Vagrant.configure("2") do |config|
-
-  #
-  # Run Ansible from the Vagrant Host
-  #
-  config.vm.provision "ansible" do |ansible|
-    ansible.playbook = "playbook.yml"
-  end
-
-end
-```
-
-##  Options
-
-This section lists the _specific_ options for the Ansible (remote) provisioner. In addition to the options listed below, this provisioner supports the [**common options** for both Ansible provisioners](/docs/provisioning/ansible_common.html).
-
-- `ask_sudo_pass` (boolean) - require Ansible to [prompt for a sudo password](https://docs.ansible.com/intro_getting_started.html#remote-connection-information).
-
-    The default value is `false`.
-
-- `ask_vault_pass` (boolean) - require Ansible to [prompt for a vault password](https://docs.ansible.com/playbooks_vault.html#vault).
-
-    The default value is `false`.
-
-- `force_remote_user` (boolean) - require Vagrant to set the `ansible_ssh_user` setting in the generated inventory, or as an extra variable when a static inventory is used. All the Ansible `remote_user` parameters will then be overridden by the value of `config.ssh.username` of the [Vagrant SSH Settings](/docs/vagrantfile/ssh_settings.html).
-
-    If this option is set to `false` Vagrant will set the Vagrant SSH username as a default Ansible remote user, but `remote_user` parameters of your Ansible plays or tasks will still be taken into account and thus override the Vagrant configuration.
-
-    The default value is `true`.
-
-    **Note:** This option was introduced in Vagrant 1.8.0. Previous Vagrant versions behave like if this option was set to `false`.
-
-- `host_key_checking` (boolean) - require Ansible to [enable SSH host key checking](https://docs.ansible.com/intro_getting_started.html#host-key-checking).
-
-    The default value is `false`.
-
-- `raw_ssh_args` (array of strings) - require Ansible to apply a list of OpenSSH client options.
-
-    Example: `['-o ControlMaster=no']`.
-
-    It is an *unsafe wildcard* that can be used to pass additional SSH settings to Ansible via `ANSIBLE_SSH_ARGS` environment variable, overriding any other SSH arguments (e.g. defined in an [`ansible.cfg` configuration file](https://docs.ansible.com/intro_configuration.html#ssh-args)).
-
-## Tips and Tricks
-
-### Ansible Parallel Execution
-
-Vagrant is designed to provision [multi-machine environments](/docs/multi-machine) in sequence, but the following configuration pattern can be used to take advantage of Ansible parallelism:
-
-```ruby
-# Vagrant 1.7+ automatically inserts a different
-# insecure keypair for each new VM created. The easiest way
-# to use the same keypair for all the machines is to disable
-# this feature and rely on the legacy insecure key.
-# config.ssh.insert_key = false
-#
-# Note:
-# As of Vagrant 1.7.3, it is no longer necessary to disable
-# the keypair creation when using the auto-generated inventory.
-
-N = 3
-(1..N).each do |machine_id|
-  config.vm.define "machine#{machine_id}" do |machine|
-    machine.vm.hostname = "machine#{machine_id}"
-    machine.vm.network "private_network", ip: "192.168.77.#{20+machine_id}"
-
-    # Only execute once the Ansible provisioner,
-    # when all the machines are up and ready.
-    if machine_id == N
-      machine.vm.provision :ansible do |ansible|
-        # Disable default limit to connect to all the machines
-        ansible.limit = "all"
-        ansible.playbook = "playbook.yml"
-      end
-    end
-  end
-end
-```
-
-**Caveats:**
-
-If you apply this parallel provisioning pattern with a static Ansible inventory, you will have to organize the things so that [all the relevant private keys are provided to the `ansible-playbook` command](https://github.com/mitchellh/vagrant/pull/5765#issuecomment-120247738). The same kind of considerations applies if you are using multiple private keys for a same machine (see [`config.ssh.private_key_path` SSH setting](/docs/vagrantfile/ssh_settings.html)).
-
-### Force Paramiko Connection Mode
-
-The Ansible provisioner is implemented with native OpenSSH support in mind, and there is no official support for [paramiko](https://github.com/paramiko/paramiko/) (A native Python SSHv2 protocol library).
-
-If you really need to use this connection mode though, it is possible to enable paramiko as illustrated in the following configuration examples:
-
-With auto-generated inventory:
-
-```
-ansible.raw_arguments = ["--connection=paramiko"]
-```
-
-With a custom inventory, the private key must be specified (e.g. via an `ansible.cfg` configuration file, `--private-key` argument, or as part of your inventory file):
-
-```
-ansible.inventory_path = "./my-inventory"
-ansible.raw_arguments  = [
-  "--connection=paramiko",
-  "--private-key=/home/.../.vagrant/machines/.../private_key"
-]
-```

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-5333e60e2d38/website/source/docs/provisioning/ansible_common.html.md

@@ -1,148 +0,0 @@
----
-layout: "docs"
-page_title: "Common Ansible Options - Provisioning"
-sidebar_current: "provisioning-ansible-common"
-description: |-
-  This page details the common options to the Vagrant Ansible provisioners.
----
-
-# Shared Ansible Options
-
-The following options are available to both Vagrant Ansible provisioners:
-
- - [`ansible`](/docs/provisioning/ansible.html)
- - [`ansible_local`](/docs/provisioning/ansible_local.html)
-
-These options get passed to the `ansible-playbook` command that ships with Ansible, either via command line arguments or environment variables, depending on Ansible own capabilities.
-
-Some of these options are for advanced usage only and should not be used unless you understand their purpose.
-
-- `config_file` (string) - The path to an [Ansible Configuration file](https://docs.ansible.com/intro_configuration.html).
-
-    By default, this option is not set, and Ansible will [search for a possible configuration file in some default locations](/docs/provisioning/ansible_intro.html#ANSIBLE_CONFIG).
-
-- `extra_vars` (string or hash) - Pass additional variables (with highest priority) to the playbook.
-
-    This parameter can be a path to a JSON or YAML file, or a hash.
-
-    Example:
-
-    ```ruby
-    ansible.extra_vars = {
-      ntp_server: "pool.ntp.org",
-      nginx: {
-        port: 8008,
-        workers: 4
-      }
-    }
-    ```
-    These variables take the highest precedence over any other variables.
-
-- `galaxy_command` (template string) - The command pattern used to install Galaxy roles when `galaxy_role_file` is set.
-
-    The following (optional) placeholders can be used in this command pattern:
-    - `%{role_file}` is replaced by the absolute path to the `galaxy_role_file` option
-    - `%{roles_path}` is
-      - replaced by the absolute path to the `galaxy_roles_path` option when such option is defined, or
-      - replaced by the absolute path to a `roles` subdirectory sitting in the `playbook` parent directory.
-
-    By default, this option is set to
-
-    `ansible-galaxy install --role-file=%{role_file} --roles-path=%{roles_path} --force`
-
-- `galaxy_role_file` (string) - The path to the Ansible Galaxy role file.
-
-    By default, this option is set to `nil` and Galaxy support is then disabled.
-
-    Note: if an absolute path is given, the `ansible_local` provisioner will assume that it corresponds to the exact location on the guest system.
-
-- `galaxy_roles_path` (string) - The path to the directory where Ansible Galaxy roles must be installed
-
-    By default, this option is set to `nil`, which means that the Galaxy roles will be installed in a `roles` subdirectory located in the parent directory of the `playbook` file.
-
-- `groups` (hash) - Set of inventory groups to be included in the [auto-generated inventory file](/docs/provisioning/ansible_intro.html).
-
-    Example:
-
-    ```ruby
-    ansible.groups = {
-      "web" => ["vm1", "vm2"],
-      "db"  => ["vm3"]
-    }
-    ```
-    Example with [group variables](https://docs.ansible.com/ansible/intro_inventory.html#group-variables):
-
-    ```ruby
-    ansible.groups = {
-      "atlanta" => ["host1", "host2"],
-      "atlanta:vars" => {"ntp_server" => "ntp.atlanta.example.com",
-                         "proxy" => "proxy.atlanta.example.com"}
-    }
-    ```
-
-    Notes:
-
-    - Alphanumeric patterns are not supported (e.g. `db-[a:f]`, `vm[01:10]`).
-    - This option has no effect when the `inventory_path` option is defined.
-
-- `host_vars` (hash) - Set of inventory host variables to be included in the [auto-generated inventory file](https://docs.ansible.com/ansible/intro_inventory.html#host-variables).
-
-    Example:
-
-    ```ruby
-    ansible.host_vars = {
-      "host1" => {"http_port" => 80,
-                  "maxRequestsPerChild" => 808},
-                  "comments" => "'text with spaces'",
-      "host2" => {"http_port" => 303,
-                  "maxRequestsPerChild" => 909}
-    }
-    ```
-
-    Note: This option has no effect when the `inventory_path` option is defined.
-
-- `inventory_path` (string) - The path to an Ansible inventory resource (e.g. a [static inventory file](https://docs.ansible.com/intro_inventory.html), 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)).
-
-    By default, this option is disabled and Vagrant generates an inventory based on the `Vagrantfile` information.
-
-- `limit` (string or array of strings) - Set of machines or groups from the inventory file to further control which hosts [are affected](https://docs.ansible.com/glossary.html#limit-groups).
-
-    The default value is set to the machine name (taken from `Vagrantfile`) to ensure that `vagrant provision` command only affect the expected machine.
-
-    Setting `limit = "all"` can be used to make Ansible connect to all machines from the inventory file.
-
-- `playbook_command` (string) - The command used to run playbooks.
-
-   The default value is `ansible-playbook`
-
-- `raw_arguments` (array of strings) - a list of additional `ansible-playbook` arguments.
-
-    It is an *unsafe wildcard* that can be used to apply Ansible options that are not (yet) supported by this Vagrant provisioner. As of Vagrant 1.7, `raw_arguments` has the highest priority and its values can potentially override or break other Vagrant settings.
-
-    Examples:
-    - `['--check', '-M', '/my/modules']`
-    - `["--connection=paramiko", "--forks=10"]`
-
-    **Caveat:** The `ansible` provisioner does not support whitespace characters in `raw_arguments` elements. Therefore **don't write** something like `["-c paramiko"]`, which will result with an invalid `" parmiko"` parameter value.
-
-- `skip_tags` (string or array of strings) - Only plays, roles and tasks that [*do not match* these values will be executed](https://docs.ansible.com/playbooks_tags.html).
-
-- `start_at_task` (string) - The task name where the [playbook execution will start](https://docs.ansible.com/playbooks_startnstep.html#start-at-task).
-
-- `sudo` (boolean) - Cause Ansible to perform all the playbook tasks [using sudo](https://docs.ansible.com/glossary.html#sudo).
-
-    The default value is `false`.
-
-- `sudo_user` (string) - set the default username who should be used by the sudo command.
-
-- `tags` (string or array of strings) - Only plays, roles and tasks [tagged with these values will be executed](https://docs.ansible.com/playbooks_tags.html) .
-
-- `vault_password_file` (string) - The path of a file containing the password used by [Ansible Vault](https://docs.ansible.com/playbooks_vault.html#vault).
-
-- `verbose` (boolean or string) - Set Ansible's verbosity to obtain detailed logging
-
-    Default value is `false` (minimal verbosity).
-
-    Examples: `true` (equivalent to `v`), `-vvv` (equivalent to `vvv`), `vvvv`.
-
-    Note that when the `verbose` option is enabled, the `ansible-playbook` command used by Vagrant will be displayed.