vagrant-aws-mkubenka 0.7.2.pre.22 → 0.7.2.pre.24

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-f3fdbf414272/website/source/docs/plugins/provisioners.html.md

@@ -1,68 +0,0 @@
----
-layout: "docs"
-page_title: "Custom Provisioners - Plugin Development"
-sidebar_current: "plugins-provisioners"
-script: |-
-  This page documents how to add new provisioners to Vagrant, allowing Vagrant
-  to automatically install software and configure software using a custom
-  provisioner. Prior to reading this, you should be familiar with the plugin
-  development basics.
----
-
-# Plugin Development: Provisioners
-
-This page documents how to add new [provisioners](/docs/provisioning/) to Vagrant,
-allowing Vagrant to automatically install software and configure software
-using a custom provisioner. Prior to reading this, you should be familiar
-with the [plugin development basics](/docs/plugins/development-basics.html).
-
-<div class="alert alert-warning">
-  <strong>Warning: Advanced Topic!</strong> Developing plugins is an
-  advanced topic that only experienced Vagrant users who are reasonably
-  comfortable with Ruby should approach.
-</div>
-
-## Definition Component
-
-Within the context of a plugin definition, new provisioners can be defined
-like so:
-
-```ruby
-provisioner "custom" do
-  require_relative "provisioner"
-  Provisioner
-end
-```
-
-Provisioners are defined with the `provisioner` method, which takes a
-single argument specifying the name of the provisioner. This is the
-name that used with `config.vm.provision` when configuring and enabling
-the provisioner. So in the case above, the provisioner would be enabled
-using `config.vm.provision :custom`.
-
-The block argument then lazily loads and returns a class that implements
-the `Vagrant.plugin(2, :provisioner)` interface, which is covered next.
-
-## Provisioner Class
-
-The provisioner class should subclass and implement
-`Vagrant.plugin(2, :provisioner)` which is an upgrade-safe way to let
-Vagrant return the proper parent class for provisioners.
-
-This class and the methods that need to be implemented are
-[very well documented](https://github.com/mitchellh/vagrant/blob/master/lib/vagrant/plugin/v2/provisioner.rb).
-The documentation on the class in the comments should be enough
-to understand what needs to be done.
-
-There are two main methods that need to be implemented: the
-`configure` method and the `provision` method.
-
-The `configure` method is called early in the machine booting process
-to allow the provisioner to define new configuration on the machine, such
-as sharing folders, defining networks, etc. As an example, the
-[Chef solo provisioner](https://github.com/mitchellh/vagrant/blob/master/plugins/provisioners/chef/provisioner/chef_solo.rb#L24)
-uses this to define shared folders.
-
-The `provision` method is called when the machine is booted and ready
-for SSH connections. In this method, the provisioner should execute
-any commands that need to be executed.

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-f3fdbf414272/website/source/docs/plugins/usage.html.md

@@ -1,74 +0,0 @@
----
-layout: "docs"
-page_title: "Plugin Usage - Plugins"
-sidebar_current: "plugins-usage"
-description: |-
-  Installing a Vagrant plugin is easy, and should not take more than a few
-  seconds.
----
-
-# Plugin Usage
-
-Installing a Vagrant plugin is easy, and should not take more than a few seconds.
-
-Please refer to the documentation of any plugin you plan on using for
-more information on how to use it, but there is one common method for
-installation and plugin activation.
-
-<div class="alert alert-warning">
-  <strong>Warning!</strong> 3rd party plugins can introduce instabilities
-  into Vagrant due to the nature of them being written by non-core users.
-</div>
-
-## Installation
-
-Plugins are installed using `vagrant plugin install`:
-
-```shell
-# Installing a plugin from a known gem source
-$ vagrant plugin install my-plugin
-
-# Installing a plugin from a local file source
-$ vagrant plugin install /path/to/my-plugin.gem
-```
-
-Once a plugin is installed, it will automatically be loaded by Vagrant.
-Plugins which cannot be loaded should not crash Vagrant. Instead,
-Vagrant will show an error message that a plugin failed to load.
-
-## Usage
-
-Once a plugin is installed, you should refer to the plugin's documentation
-to see exactly how to use it. Plugins which add commands should be instantly
-available via `vagrant`, provisioners should be available via
-`config.vm.provision`, etc.
-
-**Note:** In the future, the `vagrant plugin` command will include a
-subcommand that will document the components that each plugin installs.
-
-## Updating
-
-Plugins can be updated by running `vagrant plugin update`. This will
-update every installed plugin to the latest version. You can update a
-specific plugin by calling `vagrant plugin update NAME`. Vagrant will
-output what plugins were updated and to what version.
-
-To determine the changes in a specific version of a plugin, refer to
-the plugin's homepage (usually a GitHub page or similar). It is the
-plugin author's responsibility to provide a change log if he or she
-chooses to.
-
-## Uninstallation
-
-Uninstalling a plugin is as easy as installing it. Just use the
-`vagrant plugin uninstall` command and the plugin will be removed. Example:
-
-```shell
-$ vagrant plugin uninstall my-plugin
-```
-
-## Listing Plugins
-
-To view what plugins are installed into your Vagrant environment at
-any time, use the `vagrant plugin list` command. This will list the plugins
-that are installed along with their version.

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-f3fdbf414272/website/source/docs/providers/basic_usage.html.md

@@ -1,112 +0,0 @@
----
-layout: "docs"
-page_title: "Basic Usage - Providers"
-sidebar_current: "providers-basic-usage"
-description: |-
-  Vagrant boxes are all provider-specific. A box for VirtualBox is incompatible
-  with the VMware Fusion provider, or any other provider. A box must be
-  installed for each provider, and can share the same name as other boxes as
-  long as the providers differ. So you can have both a VirtualBox and VMware
-  Fusion "precise64" box.
----
-
-# Basic Provider Usage
-
-## Boxes
-
-Vagrant boxes are all provider-specific. A box for VirtualBox is incompatible
-with the VMware Fusion provider, or any other provider. A box must be installed
-for each provider, and can share the same name as other boxes as long
-as the providers differ. So you can have both a VirtualBox and VMware Fusion
-"precise64" box.
-
-Installing boxes has not changed at all:
-
-```
-$ vagrant box add \
-  precise64 https://files.hashicorp.com/precise64.box
-```
-
-Vagrant now automatically detects what provider a box is for. This is
-visible when listing boxes. Vagrant puts the provider in parentheses next
-to the name, as can be seen below.
-
-```
-$ vagrant box list
-precise64 (virtualbox)
-precise64 (vmware_fusion)
-```
-
-## Vagrant Up
-
-Once a provider is installed, you can use it by calling `vagrant up`
-with the `--provider` flag. This will force Vagrant to use that specific
-provider. No other configuration is necessary!
-
-In normal day-to-day usage, the `--provider` flag is not necessary
-since Vagrant can usually pick the right provider for you. More details
-on how it does this is below.
-
-```
-$ vagrant up --provider=vmware_fusion
-```
-
-If you specified a `--provider` flag, you only need to do this for the
-`up` command. Once a machine is up and running, Vagrant is able to
-see what provider is backing a running machine, so commands such as
-`destroy`, `suspend`, etc. do not need to be told what provider to use.
-
-<div class="alert alert-info">
-  Vagrant currently restricts you to bringing up one provider per machine.
-  If you have a multi-machine environment, you can bring up one machine
-  backed by VirtualBox and another backed by VMware Fusion, for example, but you
-  cannot back the <em>same machine</em> with both VirtualBox and
-  VMware Fusion. This is a limitation that will be removed in a future
-  version of Vagrant.
-</div>
-
-## Default Provider
-
-As mentioned earlier, you typically do not need to specify `--provider`
-_ever_. Vagrant is smart enough about being able to detect the provider
-you want for a given environment.
-
-Vagrant attempts to find the default provider in the following order:
-
-  1. The `--provider` flag on a `vagrant up` is chosen above all else, if
-     it is present.
-
-  2. If the `VAGRANT_DEFAULT_PROVIDER` environmental variable is set,
-     it takes next priority and will be the provider chosen.
-
-  3. Vagrant will go through all of the `config.vm.provider` calls in the
-     Vagrantfile and try each in order. It will choose the first provider
-     that is usable. For example, if you configure Hyper-V, it will never
-     be chosen on Mac this way. It must be both configured and usable.
-
-  4. Vagrant will go through all installed provider plugins (including the
-     ones that come with Vagrant), and find the first plugin that reports
-     it is usable. There is a priority system here: systems that are known
-     better have a higher priority than systems that are worse. For example,
-     if you have the VMware provider installed, it will always take priority
-     over VirtualBox.
-
-  5. If Vagrant still has not found any usable providers, it will error.
-
-Using this method, there are very few cases that Vagrant does not find the
-correct provider for you. This also allows each
-[Vagrantfile](/docs/vagrantfile/) to define what providers
-the development environment is made for by ordering provider configurations.
-
-A trick is to use `config.vm.provider` with no configuration at the top of
-your Vagrantfile to define the order of providers you prefer to support:
-
-```ruby
-Vagrant.configure("2") do |config|
-  # ... other config up here
-
-  # Prefer VMware Fusion before VirtualBox
-  config.vm.provider "vmware_fusion"
-  config.vm.provider "virtualbox"
-end
-```

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-f3fdbf414272/website/source/docs/providers/configuration.html.md

@@ -1,91 +0,0 @@
----
-layout: "docs"
-page_title: "Configuration - Providers"
-sidebar_current: "providers-configuration"
-description: |-
-  While well-behaved Vagrant providers should work with any Vagrantfile with
-  sane defaults, providers generally expose unique configuration options so that
-  you can get the most out of each provider.  
----
-
-# Configuration
-
-While well-behaved Vagrant providers should work with any Vagrantfile with sane
-defaults, providers generally expose unique configuration
-options so that you can get the most out of each provider.
-
-This provider-specific configuration is done within the Vagrantfile
-in a way that is portable, easy to use, and easy to understand.
-
-## Portability
-
-An important fact is that even if you configure other providers within
-a Vagrantfile, the Vagrantfile remains portable even to individuals who
-do not necessarily have that provider installed.
-
-For example, if you configure VMware Fusion and send it to an individual
-who does not have the VMware Fusion provider, Vagrant will silently ignore
-that part of the configuration.
-
-## Provider Configuration
-
-Configuring a specific provider looks like this:
-
-```ruby
-Vagrant.configure("2") do |config|
-  # ...
-
-  config.vm.provider "virtualbox" do |vb|
-    vb.customize ["modifyvm", :id, "--cpuexecutioncap", "50"]
-  end
-end
-```
-
-Multiple `config.vm.provider` blocks can exist to configure multiple
-providers.
-
-The configuration format should look very similar to how provisioners
-are configured. The `config.vm.provider` takes a single parameter: the
-name of the provider being configured. Then, an inner block with custom
-configuration options is exposed that can be used to configure that
-provider.
-
-This inner configuration differs among providers, so please read the
-documentation for your provider of choice to see available configuration
-options.
-
-Remember, some providers do not require any provider-specific configuration
-and work directly out of the box. Provider-specific configuration is meant
-as a way to expose more options to get the most of the provider of your
-choice. It is not meant as a roadblock to running against a specific provider.
-
-## Overriding Configuration
-
-Providers can also override non-provider specific configuration, such
-as `config.vm.box` and any other Vagrant configuration. This is done by
-specifying a second argument to `config.vm.provider`. This argument is
-just like the normal `config`, so set any settings you want, and they will
-be overridden only for that provider.
-
-Example:
-
-```
-Vagrant.configure("2") do |config|
-  config.vm.box = "precise64"
-
-  config.vm.provider "vmware_fusion" do |v, override|
-    override.vm.box = "precise64_fusion"
-  end
-end
-```
-
-In the above case, Vagrant will use the "precise64" box by default, but
-will use "precise64_fusion" if the VMware Fusion provider is used.
-
-<div class="alert alert-info">
-  <strong>The Vagrant Way:</strong> The proper "Vagrant way" is to
-  avoid any provider-specific overrides if possible by making boxes
-  for multiple providers that are as identical as possible, since box
-  names can map to multiple providers. However, this is not always possible,
-  and in those cases, overrides are available.
-</div>

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-f3fdbf414272/website/source/docs/providers/custom.html.md

@@ -1,13 +0,0 @@
----
-layout: "docs"
-page_title: "Custom Provider - Providers"
-sidebar_current: "providers-custom"
-description: |-
-  To learn how to make your own custom Vagrant providers, read the Vagrant
-  plugin development guide on creating custom providers.
----
-
-# Custom Provider
-
-To learn how to make your own custom Vagrant providers, read the Vagrant plugin
-development guide on [creating custom providers](/docs/plugins/providers.html).

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-f3fdbf414272/website/source/docs/providers/default.html.md

@@ -1,29 +0,0 @@
----
-layout: "docs"
-page_title: "Default Provider - Providers"
-sidebar_current: "providers-default"
-description: |-
-  By default, VirtualBox is the default provider for Vagrant. VirtualBox is
-  still the most accessible platform to use Vagrant: it is free, cross-platform,
-  and has been supported by Vagrant for years. With VirtualBox as the default
-  provider, it provides the lowest friction for new users to get started with
-  Vagrant.
----
-
-# Default Provider
-
-By default, VirtualBox is the default provider for Vagrant. VirtualBox is
-still the most accessible platform to use Vagrant: it is free, cross-platform,
-and has been supported by Vagrant for years. With VirtualBox as the default
-provider, it provides the lowest friction for new users to get started with
-Vagrant.
-
-However, you may find after using Vagrant for some time that you prefer
-to use another provider as your default. In fact, this is quite common.
-To make this experience better, Vagrant allows specifying the default
-provider to use by setting the `VAGRANT_DEFAULT_PROVIDER` environmental
-variable.
-
-Just set `VAGRANT_DEFAULT_PROVIDER` to the provider you wish to be the
-default. For example, if you use Vagrant with VMware Fusion, you can set
-the environmental variable to `vmware_fusion` and it will be your default.

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-f3fdbf414272/website/source/docs/providers/index.html.md

@@ -1,28 +0,0 @@
----
-layout: "docs"
-page_title: "Providers"
-sidebar_current: "providers"
-description: |-
-  While Vagrant ships out of the box with support for VirtualBox, Hyper-V, and
-  Docker. Vagrant has the ability to manage other types of machines as well.
-  This is done by using other providers with Vagrant.
----
-
-# Providers
-
-While Vagrant ships out of the box with support for [VirtualBox](https://www.virtualbox.org),
-[Hyper-V](https://www.microsoft.com/hyper-v), and [Docker](https://www.docker.io),
-Vagrant has the ability to manage other types of machines as well. This is done
-by using other _providers_ with Vagrant.
-
-Alternate providers can offer different features that make more sense in your use case.
-For example, if you are using Vagrant for any real work, [VMware](https://www.vmware.com)
-providers are recommended since they're well supported and generally more
-stable and performant than VirtualBox.
-
-Before you can use another provider, you must install it. Installation of other providers
-is done via the Vagrant plugin system.
-
-Once the provider is installed, usage is straightforward and simple, as
-you would expect with Vagrant. Read into the relevant subsections found in
-the navigation to the left for more information.

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-f3fdbf414272/website/source/docs/providers/installation.html.md

@@ -1,16 +0,0 @@
----
-layout: "docs"
-page_title: "Installation - Providers"
-sidebar_current: "providers-installation"
-description: |-
-  Providers are distributed as Vagrant plugins, and are therefore installed
-  using standard plugin installation steps. After installing a plugin which
-  contains a provider, the provider should immediately be available.
----
-
-# Provider Installation
-
-Providers are distributed as Vagrant plugins, and are therefore installed
-using [standard plugin installation steps](/docs/plugins/usage.html). After
-installing a plugin which contains a provider, the provider should
-immediately be available.

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

@@ -1,151 +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_become_pass` (boolean) - require Ansible to [prompt for a password](https://docs.ansible.com/intro_getting_started.html#remote-connection-information) when switching to another user with the [become/sudo mechanism](http://docs.ansible.com/ansible/become.html).
-
-    The default value is `false`.
-
-- `ask_sudo_pass` (boolean) - Backwards compatible alias for the [ask_become_pass](#ask_become_pass) option.
-
-    <div class="alert alert-warning">
-      <strong>Deprecation:</strong>
-      The `ask_sudo_pass` option is deprecated and will be removed in a future release. Please use the [**`ask_become_pass`**](#ask_become_pass) option instead.
-    </div>
-
-- `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`.
-
-    <div class="alert alert-info">
-      <strong>Compatibility Note:</strong>
-      This option was introduced in Vagrant 1.8.0. Previous Vagrant versions behave like if this option was set to `false`.
-    </div>
-
-- `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
-```
-
-<div class="alert alert-info">
-  <strong>Tip:</strong>
-  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)).
-</div>
-
-### 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"
-]
-```