8834afbd8e
With this change, it is now possible to get rid of many deprecation messages successively introduced in Ansible 1.9, and 2.0. More interesting, the generated inventory will contain the recommended variable names (e.g. `ansible_host` instead of `ansible_ssh_host`) when the compatibility mode is set to '2.0'. Details: - Add `compatibility_mode` option to control the Ansible parameters format to be used. The value corresponds to the minimal version supported. For the moment, possible values are '1.8' (corresponding to Vagrant's former behaviour) or '2.0'. Note that a dynamic inventory generated in compatibility mode '2.0' is not supported by Ansible 1.x. On the other hand, Ansible 2.x so far supports inventory format generated by the compatibility mode '1.8'. - Add compatibility mode auto-detection, based on the available Ansible version. This is the default behaviour in order to bring a maximum of user friendliness. The drawback of this approach is to let potential compatibility breaking risks, for `ansible` provisioner setups that already integrate Ansible 2.x **AND** rely on the existence of the generated `_ssh` variable names. Thanks to the vagrant warnings (and its release notes), I argue that it is worth to offer auto-detection by default, which offers a sweet transition to most users. - Add `become`, `become_user` and `ask_become_pass` options and their backwards compatible aliases. The legacy options are now deprecated. Note that we intentionally didn't provide a '1.9' compatibility mode, as it would add extra-complexity for practically no added-value. To my knowledge, the Ansible 2.x series haven't introduced yet any major changes or deprecations that would motivate to introduce a higher version compatibility mode (to be confirmed/verified). Resolve GH-6570 Still Pending: - Optimization: Reduce the number of `ansible` command executions. Currently two exec calls will be performed when the compatibility mode auto-detection is enabled (i.e. by default). We could make the provisioner a little bit smarter to only execute `ansible` only once in any situation (by combining "presence" and "version" checks). - User-friendliness: Add better validator on `compatibility_mode` option, and shows a warning or an error instead of the silent fallback on the auto-detection modus. - Test coverage: All the added behaviours are not fully covered yet. |
||
|---|---|---|
| .github | ||
| bin | ||
| contrib | ||
| keys | ||
| lib | ||
| plugins | ||
| scripts | ||
| tasks | ||
| templates | ||
| test | ||
| website | ||
| .gitignore | ||
| .travis.yml | ||
| .vimrc | ||
| .yardopts | ||
| CHANGELOG.md | ||
| Gemfile | ||
| LICENSE | ||
| README.md | ||
| RELEASE.md | ||
| Rakefile | ||
| Vagrantfile | ||
| vagrant-spec.config.example.rb | ||
| vagrant.gemspec | ||
| version.txt | ||
README.md
Vagrant
- Website: https://www.vagrantup.com/
- Source: https://github.com/mitchellh/vagrant
- Mailing list: Google Groups
Vagrant is a tool for building and distributing development environments.
Development environments managed by Vagrant can run on local virtualized platforms such as VirtualBox or VMware, in the cloud via AWS or OpenStack, or in containers such as with Docker or raw LXC.
Vagrant provides the framework and configuration format to create and manage complete portable development environments. These development environments can live on your computer or in the cloud, and are portable between Windows, Mac OS X, and Linux.
Quick Start
For the quick-start, we'll bring up a development machine on VirtualBox because it is free and works on all major platforms. Vagrant can, however, work with almost any system such as OpenStack, VMware, Docker, etc.
First, make sure your development machine has VirtualBox installed. After this, download and install the appropriate Vagrant package for your OS.
To build your first virtual environment:
vagrant init hashicorp/precise32
vagrant up
Note: The above vagrant up command will also trigger Vagrant to download the
precise32 box via the specified URL. Vagrant only does this if it detects that
the box doesn't already exist on your system.
Getting Started Guide
To learn how to build a fully functional development environment, follow the getting started guide.
Installing the Gem from Git
If you want the bleeding edge version of Vagrant, we try to keep master pretty stable and you're welcome to give it a shot. Please review the installation page here.
Contributing to Vagrant
To install Vagrant from source, please follow the guide in the Wiki.
You can run the test suite with:
bundle exec rake
This will run the unit test suite, which should come back all green! Then you're good to go!
If you want to run Vagrant without having to install the gem, you may use bundle exec,
like so:
bundle exec vagrant help
Acceptance Tests
Vagrant also comes with an acceptance test suite that does black-box tests of various Vagrant components. Note that these tests are extremely slow because actual VMs are spun up and down. The full test suite can take hours. Instead, try to run focused component tests.
To run the acceptance test suite, first copy vagrant-spec.config.example.rb
to vagrant-spec.config.rb and modify it to valid values. The places you
should fill in are clearly marked.
Next, see the components that can be tested:
$ rake acceptance:components
cli
provider/virtualbox/basic
...
Then, run one of those components:
$ rake acceptance:run COMPONENTS="cli"
...