This is a big commit, and I apologize in advance for the future
git-blames all pointing to me. This commit does a few things:
1. Merges the website/docs and website/www repo into a single website repo
to be in line with other HashiCorp projects
2. Updates to use middleman-hashicorp
3. Converts less to scss to be in line with other projects
4. Updates page styles to be in line with other projects
5. Optimizes images
6. Prepare for S3 + Fastly deployment with scripts, etc.
7. Removes blog posts (they have been transferred to hashicorp.com with
redirects in place
8. Updated sitemap generation script for better SEO
9. Fixed many broken links
10. Add description to all fields
With this change, the existing host-based Ansible provisioner is
refactored to share a maximum of code with this new guest-based Ansible
provisioner.
At this stage of development, the existing unit tests are intentionally
modified as little as possible, to keep safe the existing funtionalities.
Other issues resolved by this changeset:
- Display a warning when running from a Windows host [GH-5292]
- Do not run `ansible-playbook` in verbose mode when the `verbose` option
is set to an empty string.
The benefits of the following "breaking change" are the following:
- default behaviour naturally fits with most common usage (i.e. always
connect with Vagrant SSH settings)
- the autogenerated inventory is more consistent by providing both the
SSH username and private key.
- no longer needed to explain how to override Ansible `remote_user` parameters
Important: With the `force_remote_user` option, people still can fall
back to the former behavior (prior to Vagrant 1.8.0), which means that
Vagrant integration capabilities are still quite open and flexible.
As of Vagrant 1.7+, the ansible parallel provisioning trick is easier to
be implemented with `config.ssh.insert_key=false` (fallback to previous
behaviour).
Close#5048
[ci skip]
Like Vagrant's default SSH behaviors (e.g ssh or ssh-config commands),
the Ansible provisioner should by default not modify or read the user
known host file (e.g. ~/.ssh/known_hosts).
Given that `UserKnownHostsFile=/dev/null` SSH option is usually combined
with `StrictHostKeyChecking=no`, it seems quite reasonable to bind the
activation/disactivation of both options to `host_key_checking`
provisioner attribute.
For the records, a discussion held in Ansible-Development mailing list
clearly confirmed that there is no short-term plan to adapt Ansible to
offer an extra option or change the behavior of
ANSIBLE_HOST_KEY_CHECKING. For this reason, the current implementation
seems reasonable and should be stable on the long run.
Close#3900
Related References:
- https://groups.google.com/forum/#!msg/ansible-devel/iuoZs1oImNs/6xrj5oa1CmoJ
- https://github.com/ansible/ansible/issues/9442
- force `--connection=ssh` (any other modes like paramiko or smart are not
supported)
- give the highest priority to `raw_arguments` for sake of simplicity (in
usage, in code and in documentation)
- fix position of the `--limit` argument (the generated inventory could be
shadowed by `raw_arguments`, while ansible.limit was able to override
`raw_arguments`
ref #3396
When `--connection` argument is not specified, Ansible will use the
'smart' mode, which can either use `ssh` or `paramiko` transports,
depending of the version of OpenSSH available. If OpenSSH version is new
enough to support ControlPersist technology, `ssh` will be used.
See also http://docs.ansible.com/intro_configuration.html#transport.
In order to support some advanced features of Vagrant (e.g. multiple ssh
private key identities or ssh forwarding), the Ansible provisioner
already must force `ssh` connection mode.
Having to deal with the possible fallback to `paramiko` increase the
burden of special cases that Ansible provisioner must handle, without
any added value, as Vagrant is based on OpenSSH and its users are
usually using modern operating systems.
With this change, the Ansible provisioner will officially only support
`ssh`. It will still be possible to switch to another connection mode
via `raw_arguments`, but it will breach the "contract", and no
(community) support can be expected in such use case.
ref #3900, #3396
Since the Ansible provisioner now potentially exports ANSIBLE_SSH_ARGS
variable, it is fair to allow to extend the content of this environment
variable (`ssh_args` parameters from ansible.cfg file have lower
priority)
- Support arbitrary depth of "groups of groups of ... groups"
- Skip ':vars' suffix, but allow group names with ':' (yes, Ansible
accepts this character)
- Like for groups of machines, groups of groups can result "empty", but
it is not an issue for Ansible. Recursive filter on the group tree is
a bit hard to implement, and don't brind real added value at Vagrant
level.
The Ansible provisioner will now only create a single inventory file named,
"vagrant_ansible_inventory". All defined Vagrant machines will be added to
this inventory file. Provisioning will now include a "--limit=#{machine}"
option to scope Ansible provisioning tasks to just the current machine. Setting
the Ansible provisioner's "limit" config option will override the new default
limit. Ansible provisioning scripts will now have access to all other defined
machines and what groups they reside in.
Without this change, it is not possible to pass more than one "raw"
argument, which was not the expected behavior. In addition to Array
format, String (for a single argument) is still accepted (for sake of
"backward compatibility" and ease of use).
Note: Due to low/expert usage of this option, I think that it is not
necessary to add more robust validation on this parameter (e.g. Array
of String type checking or argument syntax pattern matching). Use it at
your own risk ;-)
Seth Vargo
Gilles Cornu
follower
Mark Whelan
Emilien Kenler
Jaik Dean
jjshoe
Mark Aaron Shirley
Mitchell Hashimoto
Matthew Johnson