Use an alias to access the datastore host. This way, it's easier
to use an existing NFS server.
We can also disable the `write` access on the iso datastore.
This fixes a regression that was caused by switching from copy() to
deepcopy() when 'saving' variables before templating. Since HostVars
did not implement the __deepcopy__() method, deepcopy returned incorrect
results when host vars were present in the variables.
Fixes#63940
This is a change to the regression tests only. These tests were failing because of leftover device settings from previous tests:
- existing `channel-group` configurations on non-test interfaces were included in the before/after counts
- fixed by using the `nxos_lag_interfaces` module with `state: deleted` to remove `channel-group` configur
ations from all interfaces
- existing `L2` `port-channel` interfaces with the same ID as the test `channel-group` ID may prevent configuring `channel-group` on the test ethernet interface
- fixed by removing `port-channel` interfaces with the same ID; e.g.
```
interface port-channel98
switchport
switchport mode trunk
nx-1(config-if)# interface Ethernet1/19
nx-1(config-if)# channel-group 98
command failed: port not compatible [switching port]
```
Fixes passed on `N6K,N7K,N9K,N3K` (internal TBs: `dt-n9k5-1,n6k-77,n7k-99,n7k-j,n3k-173,evergreen-nx-1,greensboro-nx-1,hamilton-nx-1,camden-nx-1`)
The error below occurs when attempting to run `ansible-playbook` with nxos regression tests.
```
fatal: [dt-n9k5-1.cisco.com]: FAILED! => {
"changed": false,
"invocation": {
"module_args": {
"commands": [
"show interface brief | json"
],
"timeout": 60
}
},
"msg": "Unsupported parameters for (nxos_command) module: timeout Supported parameters include: commands, interval, match, provider, retries, wait_for"
}
```
This error appears to be a result of https://github.com/ansible/ansible/pull/62625, but that has not been verified.
* docker_login: Use with statement for accessing files (#64382)
* Update changelogs/fragments/64382-docker_login-fix-invalid-json.yml
Co-Authored-By: Felix Fontein <felix@fontein.de>
* Use "default" route info to help pick the default address.
Before this change, the address information used for the "default_ipv4"
and "default_ipv6" information is whatever is first on the interface
identified by the looking up the "default" route. On OpenBSD at
least, the first IPv6 address tends to be a link-local address,
which is not useful if you want to try and put a globally routable
v6 address in a template somewhere.
OpenBSD and NetBSD list the local address used for the default
route, so we can then use that to filter the addresses on the
interface and use the right one when it is available. This should
also help in situations where the interface has a lot of aliases,
or if you're doing IP multipath.
Thanks to John-Mark Gurney and Jared McNeill for providing me output
from the route command on FreeBSD and NetBSD respectively.
* Use "route get default" to get default route information.
Using some other arbitrary address makes these facts produce
unexpected results in some situations.
