There are changes that the merge config can fail, but the module
will still report success. This adds a blob of code to start
collecting those failures and bubbling up a module failure
accordingly.
* adding azure_rm_mysqldatabase
* updates to azure_rm_mysqldatabase
* updates to azure_rm_mysqldatabase
* updates to azure_rm_mysqldatabase
* updates to azure_rm_mysqldatabase
* updates to azure_rm_mysqldatabase
* updates to azure_rm_mysqldatabase
* Updated docs around force_update
* adding azure_rm_postgresqldatabase
* updates to azure_rm_postgresqldatabase
* updates to azure_rm_postgresqldatabase
* updates to azure_rm_postgresqldatabase
* updates to azure_rm_postgresqldatabase
* updates to azure_rm_postgresqldatabase
* updates to azure_rm_postgresqldatabase
* Updated docs around force_update
* describe_images is very slow if not filtered to owner accounts
*or* if the Owners parameter is passed (unless the Owners parameter
is `self`). Convert Owners parameters to `owner-id` and `owner-alias`
filters where possible. Tests with CLI show that `--owners self` is
fast, `--owners 123456789012` is slow (with or without owner-id filter).
* describe_image_attributes fails against accounts other than your
own. Launch permissions are useful information, but not critical.
* first dirty container instance
* added my name ;-)
* more updates
* more updates
* removed unnecessary stuff
* container instance updates
* several fixes
* undo changes in common
* removed unnecessary references, fixed delete
* added / updated parameters
* updated samples & comments
* updated docs, comments, samples and added registry credentials
* added ip address and port
* query existing container instance (but result not used yet)
* some major changes to the module
* more fixes
* added requirement for containerinstance module
* adding integration test
* fixes for pull request
* updated version
* updated version to 2.5
* updated version
* updated integration.cloud.azure.txt as requested by test framework
* removed due to merge reasons
* updated requirements-azure.txt
* undone azure-rm-common
* lf
* properly update test requirements
* first dirty container instance
* container instance updates
* several fixes
* review related updates
* review related fixes
* undo changes in common
* added / updated parameters
* query existing container instance (but result not used yet)
* updated version to 2.5
* updated version
* removed due to merge reasons
* updated requirements-azure.txt
* undone azure-rm-common
* properly update test requirements
* minor fix - sanity
* fix one issue after rebasing
* removed files accidentally added while rebasing
* removed checking for changes
* several fixes
* fixed sanity
* updates as requested by reviewers
* removed ci as it doesn't work
* reenabled ci
* renamed container instance, removed required: false
* removed default: null
* final updates according to the review
* one more fix
* first dirty container instance
* added my name ;-)
* more updates
* more updates
* removed unnecessary stuff
* container instance updates
* several fixes
* undo changes in common
* removed unnecessary references, fixed delete
* added / updated parameters
* updated samples & comments
* updated docs, comments, samples and added registry credentials
* added ip address and port
* query existing container instance (but result not used yet)
* some major changes to the module
* more fixes
* adding integration test
* fixes for pull request
* updated version
* updated version to 2.5
* updated version
* updated integration.cloud.azure.txt as requested by test framework
* removed due to merge reasons
* updated requirements-azure.txt
* undone azure-rm-common
* lf
* properly update test requirements
* review related updates
* first dirty container instance
* container instance updates
* several fixes
* review related fixes
* undo changes in common
* added / updated parameters
* query existing container instance (but result not used yet)
* updated version to 2.5
* updated version
* removed due to merge reasons
* updated requirements-azure.txt
* undone azure-rm-common
* properly update test requirements
* minor fix - sanity
* fix one issue after rebasing
* removed files accidentally added while rebasing
* removed checking for changes
* several fixes
* fixed sanity
* updates as requested by reviewers
* removed ci as it doesn't work
* reenabled ci
* renamed container instance, removed required: false
* removed default: null
* final updates according to the review
* one more fix
* changed location as default from resource group can't handle containers
* updates to container instance
* fixed mistakes during merge
* one more fix
* another mistake
* container instance fixes
* several fixes to container instance
* return value fix
* minor update
* just one api version right now
* fixed api version
* container instance does not suppurt api version
* removed unnecessary try blocks
* removed tags related things
* fixed pep8
* final fixes?
* final updates to the module
* more fixes
* Fix ec2_vpc_net tags
PR #33105 broke the tags returned by ec2_vpc_net - it was returning the raw boto3 list instead of a dict as expected.
* Add a test for tags
* `validate` or `ignore` values may be set by module, credential profile, or env. Module has highest precedence, followed by credential profile, then environment, and defaults to `validate` if not otherwise specified.
* fixes#33455
* add lib/ansible/plugins/connection/lxd.py maintainer in BOTMETA.yaml
Signed-off-by: Adam Miller <admiller@redhat.com>
* github nick change for trstringer on team_azure in BOTMETA
Signed-off-by: Adam Miller <admiller@redhat.com>
* IP address pool module and integration tests
* Examples corrected and imports moved to beginning of module.
* Revert ucsmsdk import lines to avoid import sanity test failures.
* Add comment around imports for ucsmsdk.
* Module DOCUMENTATION should match argspec
Large update of many modules so that DOCUMENTATION option name and
aliases match those defined in the argspec.
Issues identified by https://github.com/ansible/ansible/pull/34809
In addition to many typos and missing aliases, the following notable
changes were made:
* Create `module_docs_fragments/url.py` for `url_argument_spec`
* `dellos*_command` shouldn't have ever had `waitfor` (was incorrectly copied)
* `ce_aaa_server_host.py` `s/raduis_server_type/radius_server_type/g`
* `Junos_lldp` enable should be part of `state`.
Fixes # 34917
* Remove spaces from in between interface name
* Convert interface name to lower case as interface name
is case insensitive wrt configuring on remote device.
* Add VnicProfileMapping to register VM
Add vnic profile mappings to be supported in vm registration
* Add VnicProfileMapping to register template
Add vnic profile mappings to be supported in template registration
* Add reassign bad macs to register VM
Add reassign bad macs to be supported in vm registration.
* Add additional mappings params for VM registration
As part of the effort to support DR with oVirt
the "Register" operation is being added with a new mapping parameter
that describes the configuration of the registration.
The idea of supporting DR site to site in oVirt is to have 2 active
setups using storage replication between the primary setup and the
secondary setup.
Both setups will have active DCs, clusters, and hosts, although those
will not be identical.
The user can define a mapping which will be used to recover its setup.
Each mapping can be used to map any VM's attribute stored in the OVF
with its correlated entity.
For example, there could be a primary setup with a VM configured on cluster A.
We also keep an active secondary setup which only have cluster B.
Cluster B is compatible for that VM and in case of a DR scenario theoretically
the storage domain can be imported to the secondary setup and the use can
register the VM to cluster B.
In that case, we can automate the recovery process by defining a cluster mapping,
so once the entity will be registered its OVF will indicate it belongs to
cluster A but the mapping which will be sent will indicate that cluster B should
be valid for every thing that is configured on cluster A.
The engine should do the switch, and register the VM to cluster B in the secondary site.
Cluster mapping is just one example.
The following list describes the different mappings which were
introduced:
LUN mapping
Role mapping
Permissions mapping
Affinity group mapping
Affinity label mapping
Each mapping will be used for its specific OVF's data once the register operation
will take place in the engine.
* Add additional mappings params for Template registration
As part of the effort to support DR with oVirt
the "Register" operation is being added with a new mapping parameter
that describes the configuration of the registration.
The idea of supporting DR site to site in oVirt is to have 2 active
setups using storage replication between the primary setup and the
secondary setup.
Both setups will have active DCs, clusters, and hosts, although those
will not be identical.
The user can define a mapping which will be used to recover its setup.
Each mapping can be used to map any Template's attribute stored in the OVF
with its correlated entity.
For example, there could be a primary setup with a Template configured on cluster A.
We also keep an active secondary setup which only have cluster B.
Cluster B is compatible for that Template and in case of a DR scenario theoretically
the storage domain can be imported to the secondary setup and the use can
register the Template to cluster B.
In that case, we can automate the recovery process by defining a cluster mapping,
so once the entity will be registered its OVF will indicate it belongs to
cluster A but the mapping which will be sent will indicate that cluster B should
be valid for every thing that is configured on cluster A.
The engine should do the switch, and register the Template to cluster B in the
secondary site.
Cluster mapping is just one example.
The following list describes the different mappings which were
introduced:
Role mapping
Permissions mapping
Each mapping will be used for its specific OVF's data once the register operation
will take place in the engine.
* Add support for update OVF store
Add support for task of update OVF store in a storage domain.
* allow shells to have per host options, remote_tmp
added language to shell
removed module lang setting from general as plugins have it now
use get to avoid bad powershell plugin
more resilient tmp discovery, fall back to `pwd`
add shell to docs
fixed options for when frags are only options
added shell set ops in t_e and fixed option frags
normalize tmp dir usag4e
- pass tmpdir/tmp/temp options as env var to commands, making it default for tempfile
- adjusted ansiballz tmpdir
- default local tempfile usage to the configured local tmp
- set env temp in action
add options to powershell
shift temporary to internal envvar/params
ensure tempdir is set if we pass var
ensure basic and url use expected tempdir
ensure localhost uses local tmp
give /var/tmp priority, less perms issues
more consistent tempfile mgmt for ansiballz
made async_dir configurable
better action handling, allow for finally rm tmp
fixed tmp issue and no more tempdir in ballz
hostvarize world readable and admin users
always set shell tempdir
added comment to discourage use of exception/flow control
* Mostly revert expand_user as it's not quite working.
This was an additional feature anyhow.
Kept the use of pwd as a fallback but moved it to a second ssh
connection. This is not optimal but getting that to work in a single
ssh connection was part of the problem holding this up.
(cherry picked from commit 395b714120522f15e4c90a346f5e8e8d79213aca)
* fixed script and other action plugins
ensure tmpdir deletion
allow for connections that don't support new options (legacy, 3rd party)
fixed tests
When using the -c option, like "ansible-config -c ~/.ansible.cfg view"
with python 3, it fail with this error message:
ERROR! Unsupported configuration file extension for b'/home/misc/.ansible.cfg': .cfg
* port elb_classic_facts to boto3
update module to use AnsibleAWSModule
* Add RETURN docs for elb_classic_lb_facts
* Remove superfluous exception handling around connection
Fix exit_json call and RETURN docs
This fixes fact gathering of VMware guest machines with
older Linux Kernel versions. These older Kernels do not support /sys
filesystem which is used to gather virtualization related facts.
'dmidecode' is the safest option to find out virtualization related facts.
Fixes: #21573
Signed-off-by: Abhijeet Kasurde <akasurde@redhat.com>
Stéphane Travassac