* ecs_ecr: Remove registry ID from create repository call
[Boto3 documentation][1] specifies 'repositoryName' as the only expected
argument. The `**build_kwargs(registry_id)` part also adds 'registryId' which,
when executed, fails with: 'Unknown parameter in input: “registryId”, must be
one of: repositoryName'.
[AWS API documentation][2] also lists only the 'repositoryName' parameter. I.e.
this is not a problem with the boto3 library.
The default registry ID for the account that's making the request will be used
when creating the rpository. This means that if the `registry_id` specified by
the user is different from the default registry ID, then the policy changes
following the repository creation would fail, because the repository will have
been created in one repository but subsequent calls try to modify it in
another. Added a safeguard against this scenario.
[1]: https://boto3.readthedocs.io/en/latest/reference/services/ecr.html#ECR.Client.create_repository
[2]: https://docs.aws.amazon.com/AmazonECR/latest/APIReference/API_CreateRepository.html
* Fix concurrent ECR integration tests
If the `ecr_name` is the same in multiple concurrent test runs, then they can
interfere with one another causing both to fail. The `resource_prefix` is
guaranteed to be unique for different jobs running in CI an so avoids this
issue while also making it easier to identify the test which created the
resource.
* 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