- The implicit default limit is always set
- ansible.limit as an empty string won't disable the default limit, but
will be passed as "--limit=" argument and ansible-playbook will return
an error (provided host list is empty)
- 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.
Except ':children' for groups of groups, it is safer to avoid generating
':suffix' blocks. At the moment Ansible only supports (but doesn't
recommend) group variables (:vars), and the Vagrant Ansible provisioner
won't support this way to define variables.
Syntax errors in `ansible.groups` definition are not well handled:
Error returned: undefined method `each' for "machine1":String (NoMethodError)
Being tolerant here doesn't hurt and may avoid people get
confused/annoyed.
env.active_machines can potentiall return 'invalid' machines:
- Ignore machines that are not declared in current Vagrantfile
- Warn when machines are missing (it usually occurs when the VM is
removed without `vagrant destroy` and some orphan metadata remains
in .vagrant/machines/...)
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 ;-)
In eb70c0d6bb we were trying to compare a Subprocess::Result to a
Fixnum, resulting in Vagrant always reporting failure regardless of
Ansible's exit code.
Gilles Cornu
Mark Aaron Shirley
Mitchell Hashimoto
Matthew Johnson
egghead
jabclab
Ben Mabey
Ches Martin
Collin Allen