Like in the (remote) `ansible` provisioner, it is preferred to pass the
directory that contains the generated inventory file. This way, advanced
inventory usages can be achieved by adding more inventory files into the
same directory.
Related to #2103 and #6500
[ci skip]
Vagrant should only consider the host-only interfaces used by the
virtual machine in the IPv6 fixup code. There may be other interfaces
present on the system with IPv6 addresses that for various reasons
would fail the routing check (for example, an interface with no
machines attached).
The patch changes the behavior to not scan all of the host-only
interfaces and adds a unit test for the behavior (that the correct IP
is validated).
Lastly, there is a small fix here that may not be an issue for most
people where the IPv6 prefix was asummed to be a multiple of 16 for
the purposes of constructing the UDP probe datagram. This assumption
has been removed.
Fixes#6586
- clearly mention that this feature is available since Vagrant 1.8.0
- reorganize the special notes
- update the examples to be more focused, and mention that a host range
is not coherent with `Vagrantfile` machine definitions.
With the introduction of inventory variables, group members provided as
String are not splitted (by ' ') into an array (instead of
auto-conversion to a single-item array).
String and Symbol types are different when used as a Hash key. By
default the Vagrant machine names are set in Symbol format, but users
may write their `host_vars` entries with String keys. This is a very
simple way to ensure smooth experience, without having to coerce the
data types during the config validation (e.g. with a library like
Hashie, which is currently not in the Vagrant dependencies)
See also:
- https://bugs.ruby-lang.org/issues/5964#note-17
- https://github.com/intridea/hashie#keyconversion
Refactor and repair regular expression attempting to match present interfaces.
The refactored regular expression will match on enp* ens* eth* variants.
This helps with some confusion caused in GH-2538, since the output says:
> Running cleanup tasks for 'shell' provisioner...
But that's actually not true. It is running the cleanup tasks iff the
provisioner defined a cleanup task. This commit changes the
provisioner_cleanup middleware to only run cleanup tasks if the subclass
defines a cleanup task.
The reason we can't just check if the provisioner `respond_to?` the
`cleanup` method is because the parent provisioner base class (which
all provisioners inherit from) defines a blank cleanup method. This is
important because it means we never risk calling an unimplemented
cleanup function, and it also helps define the public API for a
provisioner.
Gilles Cornu
Seth Vargo
Timur Alperovich
Rickard von Essen
Michael Kuzmin
Kamjar Gerami
Mitchell Hashimoto
Christian Henz
Reed Loden
Joshua Harshman
Ruben Vermeersch