vagrant-aws-detiber 0.7.2.pre.2

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-419afb4dcffe/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-419afb4dcffe/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 = "--index-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-419afb4dcffe/website/source/docs/provisioning/basic_usage.html.md

@@ -0,0 +1,228 @@
+---
+layout: "docs"
+page_title: "Basic Usage - Provisioning"
+sidebar_current: "provisioning-basic"
+description: |-
+  While Vagrant offers multiple options for how you are able to provision
+  your machine, there is a standard usage pattern as well as some important
+  points common to all provisioners that are important to know.
+---
+
+# Basic Usage of Provisioners
+
+While Vagrant offers multiple options for how you are able to provision
+your machine, there is a standard usage pattern as well as some important
+points common to all provisioners that are important to know.
+
+## Configuration
+
+First, every provisioner is configured within your
+[Vagrantfile](/docs/vagrantfile/)
+using the `config.vm.provision` method call. For example, the Vagrantfile
+below enables shell provisioning:
+
+```ruby
+Vagrant.configure("2") do |config|
+  # ... other configuration
+
+  config.vm.provision "shell", inline: "echo hello"
+end
+```
+
+Every provisioner has a type, such as `"shell"`, used as the first
+parameter to the provisioning configuration. Following that is basic key/value
+for configuring that specific provisioner. Instead of basic key/value, you
+can also use a Ruby block for a syntax that is more like variable assignment.
+The following is effectively the same as the prior example:
+
+```ruby
+Vagrant.configure("2") do |config|
+  # ... other configuration
+
+  config.vm.provision "shell" do |s|
+    s.inline = "echo hello"
+  end
+end
+```
+
+The benefit of the block-based syntax is that with more than a couple options
+it can greatly improve readability. Additionally, some provisioners, like
+the Chef provisioner, have special methods that can be called within that
+block to ease configuration that cannot be done with the key/value approach,
+or you can use this syntax to pass arguments to a shell script.
+
+The attributes that can be set in a single-line are the attributes that
+are set with the `=` style, such as `inline = "echo hello"` above. If the
+style is instead more of a function call, such as `add_recipe "foo"`, then
+this cannot be specified in a single line.
+
+Provisioners can also be named (since 1.7.0). These names are used cosmetically for output
+as well as overriding provisioner settings (covered further below). An example
+of naming provisioners is shown below:
+
+```ruby
+Vagrant.configure("2") do |config|
+  # ... other configuration
+
+  config.vm.provision "bootstrap", type: "shell" do |s|
+    s.inline = "echo hello"
+  end
+end
+```
+
+Naming provisioners is simple. The first argument to `config.vm.provision`
+becomes the name, and then a `type` option is used to specify the provisioner
+type, such as `type: "shell"` above.
+
+## Running Provisioners
+
+Provisioners are run in three cases: the initial `vagrant up`, `vagrant
+provision`, and `vagrant reload --provision`.
+
+A `--no-provision` flag can be passed to `up` and `reload` if you do not
+want to run provisioners. Likewise, you can pass `--provision` to force
+provisioning.
+
+The `--provision-with` flag can be used if you only want to run a
+specific provisioner if you have multiple provisioners specified. For
+example, if you have a shell and Puppet provisioner and only want to
+run the shell one, you can do `vagrant provision --provision-with shell`.
+The arguments to `--provision-with` can be the provisioner type (such as
+"shell") or the provisioner name (such as "bootstrap" from above).
+
+## Run Once or Always
+
+By default, provisioners are only run once, during the first `vagrant up`
+since the last `vagrant destroy`, unless the `--provision` flag is set,
+as noted above.
+
+Optionally, you can configure provisioners to run on every `up` or
+`reload`. They will only be not run if the `--no-provision` flag is
+explicitly specified. To do this set the `run` option to "always",
+as shown below:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "shell", inline: "echo hello",
+    run: "always"
+end
+```
+
+You can also set `run:` to `"never"` if you have an optional provisioner
+that you want to mention to the user in a "post up message" or that
+requires some other configuration before it is possible, then call this
+with `vagrant provision --provision-with bootstrap`.
+
+If you are using the block format, you must specify it outside
+of the block, as shown below:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "shell", run: "always" do |s|
+    s.inline = "echo hello"
+  end
+end
+```
+
+## Multiple Provisioners
+
+Multiple `config.vm.provision` methods can be used to define multiple
+provisioners. These provisioners will be run in the order they're defined.
+This is useful for a variety of reasons, but most commonly it is used so
+that a shell script can bootstrap some of the system so that another provisioner
+can take over later.
+
+If you define provisioners at multiple "scope" levels (such as globally
+in the configuration block, then in a
+[multi-machine](/docs/multi-machine/) definition, then maybe
+in a [provider-specific override](/docs/providers/configuration.html)),
+then the outer scopes will always run _before_ any inner scopes. For
+example, in the Vagrantfile below:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "shell", inline: "echo foo"
+
+  config.vm.define "web" do |web|
+    web.vm.provision "shell", inline: "echo bar"
+  end
+
+  config.vm.provision "shell", inline: "echo baz"
+end
+```
+
+The ordering of the provisioners will be to echo "foo", "baz", then
+"bar" (note the second one might not be what you expect!). Remember:
+ordering is _outside in_.
+
+With multiple provisioners, use the `--provision-with` setting along
+with names to get more fine grained control over what is run and when.
+
+## Overriding Provisioner Settings
+
+<div class="alert alert-warning">
+  <strong>Warning: Advanced Topic!</strong> Provisioner overriding is
+  an advanced topic that really only becomes useful if you are already
+  using multi-machine and/or provider overrides. If you are just getting
+  started with Vagrant, you can safely skip this.
+</div>
+
+When using features such as [multi-machine](/docs/multi-machine/)
+or [provider-specific overrides](/docs/providers/configuration.html),
+you may want to define common provisioners in the global configuration
+scope of a Vagrantfile, but override certain aspects of them internally.
+Vagrant allows you to do this, but has some details to consider.
+
+To override settings, you must assign a name to your provisioner.
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "foo", type: "shell",
+    inline: "echo foo"
+
+  config.vm.define "web" do |web|
+    web.vm.provision "foo", type: "shell",
+      inline: "echo bar"
+  end
+end
+```
+
+In the above, only "bar" will be echoed, because the inline setting
+overloaded the outer provisioner. This overload is only effective
+within that scope: the "web" VM. If there were another VM defined,
+it would still echo "foo" unless it itself also overloaded the
+provisioner.
+
+**Be careful with ordering.** When overriding a provisioner in
+a sub-scope, the provisioner will run at _that point_. In the example
+below, the output would be "foo" then "bar":
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "foo", type: "shell",
+    inline: "echo ORIGINAL!"
+
+  config.vm.define "web" do |web|
+    web.vm.provision "shell",
+      inline: "echo foo"
+    web.vm.provision "foo", type: "shell",
+      inline: "echo bar"
+  end
+end
+```
+
+If you want to preserve the original ordering, you can specify
+the `preserve_order: true` flag:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "do-this",
+    type: "shell",
+    preserve_order: true,
+    inline: "echo FIRST!"
+  config.vm.provision "then-this",
+    type: "shell",
+    preserve_order: true,
+    inline: "echo SECOND!"
+end
+```