username param is read by eos action plugion load_provider, if present
it is set as the play context remote user.
That means if you have a play remote_user: admin it won't be used, but instead
whatever is put in the task argument username.
Changing the tests to use name fixes the issue, we may want to remove username
as valid module argument in other change.
* replace boto with boto3 for the s3 module
make s3 pep8 and remove from legacy files
fix s3 unit tests
* fix indentation
* s3 module - if we can't create an MD5 sum return None and always upload file
* remove Location.DEFAULT which isn't used in boto3 and tidy up the docs
* pep8
* s3: remove default: null, empty aliases, and required: false from documentation
fix incorrectly documented defaults
* Porting s3 to boto3. Simplify some logic and remove unused imports
* Fix s3 module variables
* Fix a typo in s3 module and remove from pep8 legacy files
* s3: add pagination for listing objects.
Fix logic and use head_object instead of get_object for efficiency.
Fix typo in unit test.
* Fix pagination to maintain backwards compatibility.
Fix incorrect conditional.
Remove redundant variable assignment.
Fix s3 list_object pagination to return all pages
* Use the revised List Objects API as recommended.
* Wrap call to paginated_list in a try/except
Also remembered to allow marker/prefix/max_keys to modify what keys are listed
* Simplify argument
* use of multiple chocolatey package names
It might be helpful to users, to clarify whether/when <name:> must specify a single package.
Users who are familiar with chocolatey may be accustomed to installing multiple packages in a single invocation of 'choco install'.
I believe win_chocolatey currently accepts multiple package names when state: is latest or present.
For instance, this appears to work currently:
- win_chocolatey:
name: >-
pscx
windirstat
state: latest
However, when state: is absent, uninstall is not performed if multiple package are specified.
The chocolate.log output suggests that chocolatey is treating the multiple packages as an 'exact' name of a single package name:
2017-08-10 19:04:04,087 2424 [DEBUG] - Command line: "C:\ProgramData\chocolatey\choco.exe" list --local-only --exact pscx windirstat
2017-08-10 19:04:04,087 2424 [DEBUG] - Received arguments: list --local-only --exact pscx windirstat
I find the current behavior helpful in terms of accepting multiple package names, even if uninstall must be treated differently.
It might be helpful to show an example of how multiple uninstalls can be handled by looping over them.
- win_chocolatey:
name: "{{ item }}"
state: absent
with_items:
- pscx
- windirstat
* revise per Jordan Borean. remote colon (:) from text. revise formating.
* Update win_chocolatey.py
* Use ChocolateyInstall env variable after installation
Fixes#19725 Custom install locations specified by the ChocolateyInstall
env variable in win_chocolatey
After an initial install of chocolatey, use the ChocolateyInstall
environment variable when assigning $script:executable .
* Improve process of locating "choco.exe" post-initial install
Implement feedback for locating choco:
* Check if choco.exe is in PATH, if there use this
* If not in path and ChocolateyInstall var is available, use that
* Otherwise, use the equivalent of Windows Special Folder CommonApplicationData for locating chocolatey.
(Chocolatey install (v0.10.7) uses CommonApplicationData when ChocolateyInstall is not set.)
* win_hotfix: new module to install Windows hotfixes
* revert to older module util loader style to satisfy the checks for now
* Changes from PR
* changed the test hotfix so we can run tests in shippable
* win_user_right: add module with tests
* fixed up name of module in docs
* forgot the test module
* fixed up whitespace
* changes made to win_user_right based on feedback
* moved away from using secedit to Win32 with P/Invoke
* tidied up copyright for documentation
The prompt_formats dict didn't get the 'prompt_ask_vault_pass'
item added for interactive --ask-vault-pass, which
caused "KeyError: u'prompt_ask_vault_pass'"
Fixes#27885
In answer to #2540, `aptitude` was introduced as tool of choice for running
upgrades in the apt module and installing new packages that arise as
dependencies during upgrades.
This recently lead to problems, as for example Ubuntu Xenial (16.04) ships
without aptitude (installed).
Studying the man pages of both apt-get and aptitude, it appears that we can
achieve the effects of `aptitude safe-upgrade` using
```
apt-get upgrade --with-new-pkgs --autoremove
```
while `aptitude full-upgrade` seems to be identical to `apt-get dist-upgrade`.
We use `apt-get` as described above as a fall-back in case that `aptitude`
cannot be found, issuing a warning when it does so.
Furthermore it introduces a flag `force_apt_get` which may be used to enforce
usage of apt-get (which does not issue a warning).
The integration tests are updated accordingly.
Cf. also the discussion in #27370.
Fixes#18987
* ovirt_templates: added option to name imported disk as a template
* ovirt_templates: added version_added to new attribute
* ovirt_templates: added alias for image_name and example
* added alias glance_image_disk_name for image_name
* example how to import image from glance as template
* improve description of template_image_disk_name
* Add new ITs for nxos_bgp, nxos_bgp_af, nxos_bgp_neighbor, and nxos_evpn_global
* Add nxos_facts IT and enhance existing tests
* switch nxos_feature tests to use bgp
* misc. test fixes
* Add checks for titanium in IT
* Handle non-titanium case in tests
* Add aggregate functionality to eos_vrf
* Add tests for eos_vrf aggregate option
* Remove test2 and test3 vrfs at the beginning of the eos_vrf tests
* Pull all vrfs
With aggregate, we need to get all VRFs and we then compare with
desired VRFs, instead of assuming it will be just one.
Michael Price