* Update cloudflare_dns account link
* Add SSHFP and TLSA records to cloudflare_dns module
These are record types which Cloudflare recently added support
for. They both go well together with DNSSEC.
Technically it's a bit of a simplification to use the hash_type
parameter for TLSA records. Yet, it fits with all the real world usage
I have seen, and it keeps the module from sprawling too much.
Related to #43803
Vultr API is being inconsisten in what it returns. An empty list when no
resources exists, but a dict of dict when they do. The case needs to be
handled so the module do not fail. An extra test has been added.
This commit introduces a new module called vr_startup_script_facts.
This module aims to return the list of startup scripts avaiable
avaiable in Vultr.
Sample available here:
```
"vultr_startup_script_facts": [
{
"date_created": "2018-07-19 08:52:55",
"date_modified": "2018-07-19 08:52:55",
"id": 327140,
"name": "myteststartupscript",
"script": "#!/bin/bash\necho Hello World > /root/hello",
"type": "boot"
}
]
```
This commit introduces a new module called vr_firewall_group_facts.
This module aims to return the list of firewall groups avaiable
avaiable in Vultr.
Sample available here:
```
"vultr_firewall_group_facts": [
{
"date_created": "2018-07-17 12:22:51",
"date_modified": "2018-07-17 12:24:47",
"description": "ansible-firewall-group",
"id": "fb5a0876",
"instance_count": 0,
"max_rule_count": 50,
"rule_count": 1
}
]
```
This commit introduces a new module called vr_dns_domain_facts.
This module aims to return the list of DNS domains avaiable avaiable in
Vultr.
Sample available here:
```
"vultr_dns_domain_facts": [
{
"date_created": "2018-07-19 07:31:14",
"domain": "ansibletest.com",
}
]
```
This commit introduces a new module called vr_user_facts.
This module aims to return the list of user avaiable avaiable in Vultr.
Sample available here:
```
"vultr_user_facts": [
{
"acls": [],
"api_enabled": "yes",
"email": "mytestuser@example.com",
"id": "a235b4f45e87f",
"name": "mytestuser"
}
]
```
This commit introduces a new module called vr_plan_facts.
This module aims to return the list of plan avaiable avaiable to use on
booted servers.
Sample available here:
```
"vultr_plan_facts": [
{
"available_locations": [
1
],
"bandwidth": 40.0,
"bandwidth_gb": 40960,
"disk": 110,
"id": 118,
"name": "32768 MB RAM,110 GB SSD,40.00 TB BW",
"plan_type": "DEDICATED",
"price_per_month": 240.0,
"ram": 32768,
"vcpu_count": 8,
"windows": false
}
]
```
This commit introduces a new module called vr_os_facts.
This module aims to return the list of OSes avaiable avaiable to use to
boot servers.
Sample available here:
```
"vultr_os_facts": [
{
"arch": "i386",
"family": "ubuntu",
"id": 216,
"name": "Ubuntu 16.04 i386",
"windows": false
}
]
```
This commit introduces a new module called vr_region_facts.
This module aims to return the list of region avaiable avaiable to use
where boot servers.
Sample available here:
```
"vultr_region_facts": [
{
"block_storage": false,
"continent": "Europe",
"country": "FR",
"ddos_protection": true,
"id": 24,
"name": "Paris",
"regioncode": "CDG",
"state": ""
}
]
```
This commit introduces a new module called vr_sshkey_facts.
This module aims to return the list of SSH keys avaiable in Vultr.
Sample available here:
```
"vultr_sshkey_facts": [
{
"date_created": "2018-07-10 14:49:13",
"id": "5b43c760d7d84",
"name": "me@home",
"ssh_key": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC+ZFQv3MyjtL1BMpSA0o0gIkzLVVC711rthT29hBNeORdNowQ7FSvVWUdAbTq00U7Xzak1ANIYLJyn+0r7olsdG4XEiUR0dqgC99kbT/QhY5mLe5lpl7JUjW9ctn00hNmt+TswpatCKWPNwdeAJT2ERynZaqPobENgewrwerqewqIVew7qFeZygxsPVn36EUr2Cdq7Nb7U0XFXh3x1p0v0+MbL4tiJwPlMAGvFTKIMt+EaA+AsRIxiOo9CMk5ZuOl9pT8h5vNuEOcvS0qx4v44EAD2VOsCVCcrPNMcpuSzZP8dRTGU9wRREAWXngD0Zq9YJMH38VTxHiskoBw1NnPz me@home"
}
]
```
Add `mode` option which sets permission mode of a VM in octet format
Add `owner_id` and `group_id` which set the ownership of a VM
Move the waiting for state at the end of the module, so it could fail faster if there is some error
tagged_instances will only be returned only if count_attributes and/or count_labels are used, as specified in the documentation
Update relevant tests
Add tests for mode, owner_id, group_id
* Add OpenNebula one_image_facts module
`one_image_facts` - module for gathering facts about OpenNebula images
Add integration tests
* Add an alias for ids
* Resolve newly added tests as filters
* Add code smell to test for ansible provided jinja tests as filters syntax
* Add docs for no-tests-as-filters code smell test
* Address tests as filters in new integration tests
* Address feedback
* Address feedback 2
* Refactor cloudscale API code
Move code common to all cloudscale cloud modules into a common base
class.
This is needed as a prepartion of the cloudscale_floating_ip module.
* cloudscale_floating_ip module
New cloud module to manage floating IPs on the cloudscale.ch IaaS
service.
* Warn on tests used as filters
* Update docs, add aliases for tests that fit more gramatically with test syntax
* Fix rst formatting
* Add successful filter, alias of success
* Remove renamed_deprecation, it was overkill
* Make directory alias for is_dir
* Update tests to use proper jinja test syntax
* Update additional documentation, living outside of YAML files, to reflect proper jinja test syntax
* Add conversion script, porting guide updates, and changelog updates
* Update newly added uses of tests as filters
* No underscore variable
* Convert recent tests as filter changes to win_stat
* Fix some changes related to rebasing a few integration tests
* Make tests_as_filters_warning explicitly accept the name of the test, instead of inferring the name
* Add test for tests_as_filters_warning
* Update tests as filters in newly added/modified tests
* Address recent changes to several integration tests
* Address recent changes in cs_vpc
* Improve error message in cloudscale_server module
Fix punctuation and add the full contents of "info" to the output in
case of failed API calls. This is useful in case of connection timeouts
and other error conditions where there is no response body available.
* Increase timeouts in cloudscale_server module
Increase the timeouts to not fail in case the API calls take a bit
longer than usual. The default timeout of fetch_url is 10s which is
quite short. Increase it to 30s. The timeout for waiting for a server
change is increased as well as it calls the API in a loop. Therefore
this value should be larger than the API timeout.
* Send API parameters as JSON in cloudscale_server module
Use JSON to send the POST data to the API instead of an urlencoded
string. Urlencoding is not really a good match for some Python
datatypes.
This fixes an issue when submitting a list of SSH keys which did not get
translated properly.
* Fix typo in cloudscale_server documentation
* cloudscale_sever: Replace timeout const by api_timeout param
Replace the static TIMEOUT_API constant by a user configurable
api_timeout parameter. Also eliminate the TIMEOUT_WAIT constant by
2*api_timeout. This means that the timeout to wait for server changes is
always double the timeout for API calls.
* Use Debian 9 image for cloudscale_server tests
Yanis Guenane