The test fails in the CI with a timeout of vmware_guest_tools_wait. It's
still unclear if this comes from:
- the ESXi environment
- the VM configuration, e.g: the amount of the RAM
- the ISO image itself
Ideally, we should have a light VM with the vmware-tools.
I didn't properly update the commit message via github UI. Revert, to
open a new PR.
This reverts commit 2794142eb3.
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
This looks to be causing issues for our new ansible.netcommon
collection. Revert for now, until we can properly address.
This reverts commit 53c7f8cbde.
* Refactor coverage file enumeration.
* Relocate sanitize_filename function.
* Support sets when writing JSON files.
* Generalize setting of info_stderr mode.
* Split out coverage path checking.
* Split out collection regex logic.
* Improve sanitize_filename type hints and docs.
* Clean up coverage erase command.
* Fix docs and type hints for initialize_coverage.
* Update type hints on CoverageConfig.
* Split out logic for finding modules.
* Split out arc enumeration.
* Split out powershell coverage enumeration.
* Raise verbosity level of empty coverage warnings.
* Add code coverage target analysis to ansible-test.
The edgeos_config module had a list of commands to filter out to avoid
load failures. This list had a single regular expression which caught
commands that attempted to set pre-encrypted passwords. This behavior is
undesirable for a few reasons.
* It's poorly documented. The documentation makes cryptic mention of a
return value that some commands might be filtered out, but offers no
explanation as to what they are or why.
* It's hard-coded. There's no way for the user to change or disable this
functionality, rendering the commands caught by that expression
completely unusable with the edgeos_config module.
* The obvious workaround is unsafe. The filter catches passwords that
are already encrypted, but is perfectly fine letting the user set
plain-text passwords. EdgeOS will encrypt them upon commit, but this
module encourages unsafe handling of secrets up to that point.
* It's a security vulnerability if the user doesn't know about this
behavior. While the module will warn if commands are filtered, the
user won't know what got filtered out until after the fact, and may
easily miss that warning if they are not vigilant. For something as
sensitive as setting a password, it's not hard to imagine naive use of
this module resulting in incorrect credentials being deployed.
* It provides no discernible benefit. Using the module without filtering
does not result in load failures. If those commands are indeed harmful
for some reason on (old?) versions of EdgeOS, it should be incumbent
upon the user to be scrupulous in what commands they issue, rather
than the module maintaining a blacklist of possible ways the user
might misuse their own system.
* "openssl_certificate - Add option for changing which ACME directory to use with acme-tiny. Set the default ACME directory to Let's Encrypt instead of using acme-tiny's default. (acme-tiny also uses Let's Encrypt at the time being, so no action should neccessary.)"
* "openssl_certificate - Change the required version of acme-tiny to >= 4.0.0"
self._discovered_interpreter_key is None unless a previous iteration
has attempted discovery. In that case, force re-discovery, as the
previous attempt certainly failed.
* Fix UNC path joining in the powershell shell plugin, add test
* Remove testy bits and a redundant line
* Fix style nits
* Update to use os.ntpath
* Add changelog for #66604
* Added omitted logpath parameter to win_domain
The Install-ADDSForest -LogPath param seems to have been omitted in the win_domain module. We do not use this module organisation-wide as its non trivial to change the log patch once AD is set up. I will also update docs
* Removed trailing whitespace
* Added logpath option to win_domain module docs
* Add anchor to each paramater row
* Update docs/templates/plugin.rst.j2
Co-Authored-By: Felix Fontein <felix@fontein.de>
* Insert full keys into plugin docs.
* Added visible links.
Co-authored-by: Felix Fontein <felix@fontein.de>
Update the example so that the task name matches the filename being updated
The first example shows how you might template a file to destination /etc/file.conf. The description of this task appears to have a typo as it refers to '/etc/files.conf' rather than '/etc/file.conf'
