* Add identifier option to apache2_module
There is a convention connecting the name passed to a2enmod and the one
appearing in apache2ctl -M. Not all modules follow this convention and
we have added a growing list of implicit conversions.
As a better long-term solution this adds an "identifier" option to be
able to set both strings explicitly.
* Run debian-specific tests only there
* Improve cleanup after apache2 tests
This is a follow-up/extension of https://github.com/ansible/ansible/pull/33630
* Add example for the new identifier option
* Put all debian tests in a block
* UCS LAN Connectivity Policies and integration tests
* Docs updated
* UCS LAN Connectivity Policy and integration tests
* Fix use of description in docs and argument_spec so validate-modules passes
* UCS vNIC templates and integration tests
* docs updated
* UCS vNIC template and integration test
* Update docs and argument_spec for description, mtu, and target.
This fix corrects the module state returned by github_module.
Now,
* When the release already exists, state is "ok"
* When the release is created, state is "changed"
Signed-off-by: Abhijeet Kasurde <akasurde@redhat.com>
* win_setup: Add Product ID and Product Key in facts
So this is actually a very nice way to get product key information from
systems collected centrally.
Especially with systems that have been upgraded from Windows 7 or
Windows 8 to Windows 10 may not have a valid Windows 10 product
license key printed anywhere, it was a digital license.
If you ever have to reinstall the system, you may recover the system
from the recovery partition, or the original media, but cannot upgrade
to Windows 10 for free. By collecting the product key, one can always
reinstall your free Windows upgrade.
My only question is, do we want this to be part of the default facts, as
it may be considered important information. Or should we make a special
**win_product_key_facts** ?
* Add ACPI product key support
* Add integration test
* Remove Get-ProductKey function, move inline
* win_setup: Add Product ID and Product Key in facts
So this is actually a very nice way to get product key information from
systems collected centrally.
Especially with systems that have been upgraded from Windows 7 or
Windows 8 to Windows 10 may not have a valid Windows 10 product
license key printed anywhere, it was a digital license.
If you ever have to reinstall the system, you may recover the system
from the recovery partition, or the original media, but cannot upgrade
to Windows 10 for free. By collecting the product key, one can always
reinstall your free Windows upgrade.
My only question is, do we want this to be part of the default facts, as
it may be considered important information. Or should we make a special
**win_product_key_facts** ?
* Add ACPI product key support
It is not possible to modify the load balancer configuration
for ECS Service.
As it is possible to detect this, it's nicer to fail gracefully
than return AWS's less meaningful failure message.
Fix PEP8 compliance
Otherwise, it fail with:
Traceback (most recent call last):
File \"/tmp/ansible_c1zmq3i9/ansible_module_openssl_certificate.py\", line 808, in <module>
main()
File \"/tmp/ansible_c1zmq3i9/ansible_module_openssl_certificate.py\", line 787, in main
certificate.generate(module)
File \"/tmp/ansible_c1zmq3i9/ansible_module_openssl_certificate.py\", line 692, in generate
certfile.write(str(crt))
TypeError: a bytes-like object is required, not 'str'
* Verify that acme-tiny is present
* Use run_command rather than subprocess for acme-tiny
Besides consistency with the rest of the code base, this also
add 2 bug fixes:
- ansible should no longer show "warning, junk after json" when using the module
- it also verify the return code of acme-tiny, and so fail when the
verification fail. The previous code didn't check rc, so it would continue
with a empty file
