vagrant-aws-detiber 0.7.2.pre.2

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-419afb4dcffe/website/source/docs/plugins/hosts.html.md

@@ -0,0 +1,99 @@
+---
+layout: "docs"
+page_title: "Custom Hosts - Plugin Development"
+sidebar_current: "plugins-hosts"
+description: |-
+  This page documents how to add new host OS detection to Vagrant, allowing
+  Vagrant to properly execute host-specific operations on new operating systems.
+  Prior to reading this, you should be familiar with the plugin development
+  basics.
+---
+
+# Plugin Development: Hosts
+
+This page documents how to add new host OS detection to Vagrant, allowing
+Vagrant to properly execute host-specific operations on new operating systems.
+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>
+
+Vagrant has some features that require host OS-specific actions, such as
+exporting NFS folders. These tasks vary from operating system to operating
+system. Vagrant uses host detection as well as
+[host capabilities](/docs/plugins/host-capabilities.html) to perform these
+host OS-specific operations.
+
+## Definition Component
+
+Within the context of a plugin definition, new hosts can be defined
+like so:
+
+```ruby
+host "ubuntu" do
+  require_relative "host"
+  Host
+end
+```
+
+Hosts are defined with the `host` method. The first argument is the
+name of the host. This name is not actually used anywhere, but may in the
+future, so choose something helpful. Then, the block argument returns a
+class that implements the `Vagrant.plugin(2, :host)` interface.
+
+## Implementation
+
+Implementations of hosts subclass `Vagrant.plugin("2", "host")`. Within
+this implementation, only the `detect?` method needs to be implemented.
+
+The `detect?` method is called by Vagrant very early on in its initialization
+process to determine if the OS that Vagrant is running on is this host.
+If you detect that it is your operating system, return `true` from `detect?`.
+Otherwise, return `false`.
+
+```
+class MyHost < Vagrant.plugin("2", "host")
+  def detect?(environment)
+    File.file?("/etc/arch-release")
+  end
+end
+```
+
+After detecting an OS, that OS is used for various
+[host capabilities](/docs/plugins/host-capabilities.html) that may be
+required.
+
+## Host Inheritance
+
+Vagrant also supports a form of inheritance for hosts, since sometimes
+operating systems stem from a common root. A good example of this is Linux
+is the root of Debian, which further is the root of Ubuntu in many cases.
+Inheritance allows hosts to share a lot of common behavior while allowing
+distro-specific overrides.
+
+Inheritance is not done via standard Ruby class inheritance because Vagrant
+uses a custom [capability-based](/docs/plugins/host-capabilities.html) system.
+Vagrant handles inheritance dispatch for you.
+
+To subclass another host, specify that host's name as a second parameter
+in the host definition:
+
+```ruby
+host "ubuntu", "debian" do
+  require_relative "host"
+  Host
+end
+```
+
+With the above component, the "ubuntu" host inherits from "debian." When
+a capability is looked up for "ubuntu", all capabilities from "debian" are
+also available, and any capabilities in "ubuntu" override parent capabilities.
+
+When detecting operating systems with `detect?`, Vagrant always does a
+depth-first search by searching the children operating systems before
+checking their parents. Therefore, it is guaranteed in the above example
+that the `detect?` method on "ubuntu" will be called before "debian."

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-419afb4dcffe/website/source/docs/plugins/index.html.md

@@ -0,0 +1,27 @@
+---
+layout: "docs"
+page_title: "Plugins"
+sidebar_current: "plugins"
+description: |-
+  Vagrant comes with many great features out of the box to get your environments
+  up and running. Sometimes, however, you want to change the way Vagrant does
+  something or add additional functionality to Vagrant. This can be done via
+  Vagrant plugins.
+---
+
+# Plugins
+
+Vagrant comes with many great features out of the box to get your environments up
+and running. Sometimes, however, you want to change the way Vagrant does something
+or add additional functionality to Vagrant. This can be done via Vagrant
+_plugins_.
+
+Plugins are powerful, first-class citizens that extend Vagrant using a
+well-documented, stable API that can withstand major version upgrades.
+
+In fact, most of the core of Vagrant is [implemented using plugins](https://github.com/hashicorp/vagrant/tree/master/plugins).
+Since Vagrant [dogfoods](https://en.wikipedia.org/wiki/Eating_your_own_dog_food) its own
+plugin API, you can be confident that the interface is stable and well supported.
+
+Use the navigation on the left below the "Plugins" section to learn more
+about how to use and build your own plugins.

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-419afb4dcffe/website/source/docs/plugins/packaging.html.md

@@ -0,0 +1,114 @@
+---
+layout: "docs"
+page_title: "Packaging and Distribution - Plugin Development"
+sidebar_current: "plugins-packaging"
+description: |-
+  This page documents how to organize the file structure of your plugin
+  and distribute it so that it is installable using standard installation
+  methods. Prior to reading this, you should be familiar with the plugin
+  development basics.
+---
+
+# Plugin Development: Packaging & Distribution
+
+This page documents how to organize the file structure of your plugin
+and distribute it so that it is installable using
+[standard installation methods](/docs/plugins/usage.html).
+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>
+
+## Example Plugin
+
+The best way to describe packaging and distribution is to look at
+how another plugin does it. The best example plugin available for this
+is [vagrant-aws](https://github.com/mitchellh/vagrant-aws).
+
+By using [Bundler](http://bundler.io) and Rake, building a new
+vagrant-aws package is easy. By simply calling `rake package`, a
+`gem` file is dropped into the directory. By calling `rake release`,
+the gem is built and it is uploaded to the central [RubyGems](https://rubygems.org)
+repository so that it can be installed using `vagrant plugin install`.
+
+Your plugin can and should be this easy, too, since you basically
+get this for free by using Bundler.
+
+## Setting Up Your Project
+
+To setup your project, run `bundle gem vagrant-my-plugin`. This will create a
+`vagrant-my-plugin` directory that has the initial layout to be a RubyGem.
+
+You should modify the `vagrant-my-plugin.gemspec` file to add any
+dependencies and change any metadata. View the [vagrant-aws.gemspec](https://github.com/mitchellh/vagrant-aws/blob/master/vagrant-aws.gemspec)
+for a good example.
+
+<div class="alert alert-warning">
+  <p>
+    <strong>Do not depend on Vagrant</strong> for your gem. Vagrant
+    is no longer distributed as a gem, and you can assume that it will
+    always be available when your plugin is installed.
+  </p>
+</div>
+
+Once the directory structure for a RubyGem is setup, you will want
+to modify your Gemfile. Here is the basic structure of a Gemfile for
+Vagrant plugin development:
+
+```ruby
+source "https://rubygems.org"
+
+group :development do
+  gem "vagrant", git: "https://github.com/hashicorp/vagrant.git"
+end
+
+group :plugins do
+  gem "my-vagrant-plugin", path: "."
+end
+```
+
+This Gemfile gets "vagrant" for development. This allows you to
+`bundle exec vagrant` to run Vagrant with your plugin already loaded,
+so that you can test it manually that way.
+
+The only thing about this Gemfile that may stand out as odd is the
+"plugins" group and putting your plugin in that group. Because
+`vagrant plugin` commands do not work in development, this is how
+you "install" your plugin into Vagrant. Vagrant will automatically
+load any gems listed in the "plugins" group. Note that this also
+allows you to add multiple plugins to Vagrant for development, if
+your plugin works with another plugin.
+
+Next, create a `Rakefile` that has at the very least, the following
+contents:
+
+```ruby
+require "rubygems"
+require "bundler/setup"
+Bundler::GemHelper.install_tasks
+```
+
+If you run `rake -T` now, which lists all the available rake tasks,
+you should see that you have the `package` and `release` tasks. You
+can now develop your plugin and build it!
+
+You can view the [vagrant-aws Rakefile](https://github.com/mitchellh/vagrant-aws/blob/master/Rakefile)
+for a more comprehensive example that includes testing.
+
+## Testing Your Plugin
+
+To manually test your plugin during development, use
+`bundle exec vagrant` to execute Vagrant with your plugin loaded
+(thanks to the Gemfile setup we did earlier).
+
+For automated testing, the
+[vagrant-spec](https://github.com/hashicorp/vagrant-spec)
+project provides helpers for both unit and acceptance testing
+plugins. See the giant README for that project for a detailed
+description of how to integrate vagrant-spec into your project.
+Vagrant itself (and all of its core plugins) use vagrant-spec
+for automated testing.

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-419afb4dcffe/website/source/docs/plugins/providers.html.md

@@ -0,0 +1,236 @@
+---
+layout: "docs"
+page_title: "Custom Providers - Plugin Development"
+sidebar_current: "plugins-providers"
+description: |-
+  This page documents how to add support for new providers to Vagrant, allowing
+  Vagrant to run and manage machines powered by a system other than VirtualBox.
+  Prior to reading this, you should be familiar with the plugin development
+  basics.
+---
+
+# Plugin Development: Providers
+
+This page documents how to add support for new [providers](/docs/providers/)
+to Vagrant, allowing Vagrant to run and manage machines powered by a
+system other than VirtualBox. Prior to reading this, you should be familiar
+with the [plugin development basics](/docs/plugins/development-basics.html).
+
+Prior to developing a provider you should also be familiar with how
+[providers work](/docs/providers/) from
+a user standpoint.
+
+<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>
+
+## Example Provider: AWS
+
+The best way to learn how to write a provider is to see how one is
+written in practice. To augment this documentation, please heavily
+study the [vagrant-aws](https://github.com/mitchellh/vagrant-aws) plugin,
+which implements an AWS provider. The plugin is a good example of how to
+structure, test, and implement your plugin.
+
+## Definition Component
+
+Within the context of a plugin definition, new providers are defined
+like so:
+
+```ruby
+provider "my_cloud" do
+  require_relative "provider"
+  Provider
+end
+```
+
+Providers are defined with the `provider` method, which takes a single
+argument specifying the name of the provider. This is the name that is
+used with `vagrant up` to specify the provider. So in the case above,
+our provider would be used by calling `vagrant up --provider=my_cloud`.
+
+The block argument then lazily loads and returns a class that
+implements the `Vagrant.plugin(2, :provider)` interface, which is covered
+next.
+
+## Provider Class
+
+The provider class should subclass and implement
+`Vagrant.plugin(2, :provider)` which is an upgrade-safe way to let Vagrant
+return the proper parent class.
+
+This class and the methods that need to be implemented are
+[very well documented](https://github.com/hashicorp/vagrant/blob/master/lib/vagrant/plugin/v2/provider.rb). The documentation done on the class in the comments should be
+enough to understand what needs to be done.
+
+Viewing the [AWS provider class](https://github.com/mitchellh/vagrant-aws/blob/master/lib/vagrant-aws/provider.rb) as well as the
+[overall structure of the plugin](https://github.com/mitchellh/vagrant-aws) is recommended as a strong getting started point.
+
+Instead of going in depth over each method that needs to be implemented,
+the documentation will cover high-level but important points to help you
+create your provider.
+
+## Box Format
+
+Each provider is responsible for having its own box format. This is
+actually an extremely simple step due to how generic boxes are. Before
+explaining you should get familiar with the general
+[box file format](/docs/boxes/format.html).
+
+The only requirement for your box format is that the `metadata.json`
+file have a `provider` key which matches the name of your provider you
+chose above.
+
+In addition to this, you may put any data in the metadata as well
+as any files in the archive. Since Vagrant core itself does not care,
+it is up to your provider to handle the data of the box. Vagrant core
+just handles unpacking and verifying the box is for the proper
+provider.
+
+As an example of a couple box formats that are actually in use:
+
+* The `virtualbox` box format is just a flat directory of the contents
+  of a `VBoxManage export` command.
+
+* The `vmware_fusion` box format is just a flat directory of the
+  contents of a `vmwarevm` folder, but only including the bare essential
+  files for VMware to function.
+
+* The `aws` box format is just a Vagrantfile defaulting some configuration.
+  You can see an [example aws box unpacked here](https://github.com/mitchellh/vagrant-aws/tree/master/example_box).
+
+Before anything with your provider is even written, you can verify
+your box format works by doing `vagrant box add` with it. When you do
+a `vagrant box list` you can see what boxes for what providers are installed.
+
+You do _not need_ the provider plugin installed to add a box for that
+provider.
+
+<a name="actions"></a>
+## Actions
+
+Probably the most important concept to understand when building a
+provider is the provider "action" interface. It is the secret sauce that
+makes providers do the magic they do.
+
+Actions are built on top of the concept of
+[middleware](https://github.com/mitchellh/middleware), which
+allow providers to execute multiple distinct steps, have error recovery
+mechanics, as well as before/after behaviors, and much more.
+
+Vagrant core requests specific actions from your provider through the
+`action` method on your provider class. The full list of actions requested
+is listed in the comments of that method on the superclass. If your
+provider does not implement a certain action, then Vagrant core will show
+a friendly error, so do not worry if you miss any, things will not explode
+or crash spectacularly.
+
+Take a look at how the VirtualBox provider
+[uses actions to build up complicated multi-step processes](https://github.com/hashicorp/vagrant/blob/master/plugins/providers/virtualbox/action.rb#L287). The AWS provider [uses a similar process](https://github.com/mitchellh/vagrant-aws/blob/master/lib/vagrant-aws/action.rb).
+
+## Built-in Middleware
+
+To assist with common tasks, Vagrant ships with a set of
+[built-in middleware](https://github.com/hashicorp/vagrant/tree/master/lib/vagrant/action/builtin). Each of the middleware is well commented on the behavior and options
+for each, and using these built-in middleware is critical to building
+a well-behaved provider.
+
+These built-in middleware can be thought of as a standard library for
+your actions on your provider. The core VirtualBox provider uses these
+built-in middleware heavily.
+
+## Persisting State
+
+In the process of creating and managing a machine, providers generally need
+to store some sort of state somewhere. Vagrant provides each machine with
+a directory to store this state.
+
+As a use-case example for this, the VirtualBox provider stores the UUID
+of the VirtualBox virtual machine created. This allows the provider to track
+whether the machine is created, running, suspended, etc.
+
+The VMware provider actually copies the entire virtual machine into this
+state directory, complete with virtual disk drives and everything.
+
+The directory is available from the `data_dir` attribute of the `Machine`
+instance given to initialize your provider. Within middleware actions, the
+machine is always available via the `:machine` key on the environment. The
+`data_dir` attribute is a Ruby [Pathname](http://www.ruby-doc.org/stdlib-1.9.3/libdoc/pathname/rdoc/Pathname.html) object.
+
+It is important for providers to carefully manage all the contents of
+this directory. Vagrant core itself does little to clean up this directory.
+Therefore, when a machine is destroyed, be sure to clean up all the state
+from this directory.
+
+## Configuration
+
+Vagrant supports [provider-specific configuration](/docs/providers/configuration.html),
+allowing for users to finely tune and control specific providers from
+Vagrantfiles. It is easy for your custom provider to expose custom configuration
+as well.
+
+Provider-specific configuration is a special case of a normal
+[configuration plugin](/docs/plugins/configuration.html). When defining the
+configuration component, name the configuration the same as the provider,
+and as a second parameter, specify `:provider`, like so:
+
+```
+config("my_cloud", :provider) do
+  require_relative "config"
+  Config
+end
+```
+
+As long as the name matches your provider, and the second `:provider`
+parameter is given, Vagrant will automatically expose this as provider-specific
+configuration for your provider. Users can now do the following in their
+Vagrantfiles:
+
+```
+config.vm.provider :my_cloud do |config|
+  # Your specific configuration!
+end
+```
+
+The configuration class returned from the `config` component in the plugin
+is the same as any other [configuration plugin](/docs/plugins/configuration.html),
+so read that page for more information. Vagrant automatically handles
+configuration validation and such just like any other configuration piece.
+
+The provider-specific configuration is available on the machine object
+via the `provider_config` attribute. So within actions or your provider class,
+you can access the config via `machine.provider_config`.
+
+<div class="alert alert-info">
+  <strong>Best practice:</strong> Your provider should <em>not require</em>
+  provider-specific configuration to function, if possible. Vagrant
+  practices a strong <a href="https://en.wikipedia.org/wiki/Convention_over_configuration">convention over configuration</a>
+  philosophy. When a user installs your provider, they should ideally
+  be able to <code>vagrant up --provider=your_provider</code> and
+  have it just work.
+</div>
+
+## Parallelization
+
+Vagrant supports parallelizing some actions, such as `vagrant up`, if the
+provider explicitly supports it. By default, Vagrant will not parallelize a
+provider.
+
+When parallelization is enabled, multiple [actions](#actions) may be run
+in parallel. Therefore, providers must be certain that their action stacks
+are thread-safe. The core of Vagrant itself (such as box collections, SSH,
+etc.) is thread-safe.
+
+Providers can explicitly enable parallelization by setting the `parallel`
+option on the provider component:
+
+```ruby
+provider("my_cloud", parallel: true) do
+  require_relative "provider"
+  Provider
+end
+```
+
+That is the only change that is needed to enable parallelization.

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

@@ -0,0 +1,68 @@
+---
+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/hashicorp/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/hashicorp/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-419afb4dcffe/website/source/docs/plugins/usage.html.md

@@ -0,0 +1,74 @@
+---
+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.