ansible-collections / ansible-collections/google.cloud
gcp_compute_disk doesn't work with a registered gcp_compute_snapshot source
- Dominant language
- Python
- Stars
- 105
- Forks
- 144
- Avg merge
- 5d 10h
- Merged PRs (30d)
- 4
Description
##### SUMMARY
when `gcp_compute_snapshot` is used to obtain a source snapshot and then given to `gcp_compute_disk` via `source_snapshot` arg, the disk creation fails with:
> "msg": "GCP returned error: {'error': {'code': 400, 'message': \"Invalid value for field 'resource.sourceSnapshot': `'********/disks/********'`. Unexpected resource collection 'disks'.\", 'errors': [{'message': \"Invalid value for field 'resource.sourceSnapshot': `'********/disks/********'`. Unexpected resource collection 'disks'.\", 'domain': 'global', 'reason': 'invalid'}]}}"
it seems to only work if supplied using `selfLink` dictionary instead of the registered variable. This contradicts the documentation:
> The source snapshot used to create this disk. You can provide this as a partial or full URL to the resource. This field represents a link to a Snapshot resource in GCP. It can be specified in two ways. First, you can place a dictionary with key 'selfLink' and value of your resource's selfLink Alternatively, you can add `register: name-of-resource` to a gcp_compute_snapshot task and then set this source_snapshot field to "{{ name-of-resource }}"
The second way does not seem to work. Only the first method (providing `selfLink`) seemed to work. Bizarrely, it seems to obfuscate its own parameters in the output, I'm not sure if it's giving these obfuscated to the API? (also not sure why these would be set as no_log in the first place?):
```
The full traceback is: [236/54831]
File "/tmp/ansible_gcp_compute_disk_payload_xt__r__b/ansible_gcp_compute_disk_payload.zip/ansible_collections/google/cloud/plugins/module_utils/gcp_utils.py", line 312, in raise_for_status
response.raise_for_status()
File "/home/scott/src/setup/venv/lib/python3.8/site-packages/requests/models.py", line 943, in raise_for_status
raise HTTPError(http_error_msg, response=self)
fatal: [localhost]: FAILED! => {
"changed": false,
"invocation": {
"module_args": {
"auth_kind": "serviceaccount",
"description": null,
"disk_encryption_key": null,
"env_type": null,
"labels": null,
"licenses": null,
"name": "mydisk",
"physical_block_size_bytes": null,
"project": "myproject",
"scopes": [
"https://www.googleapis.com/auth/compute"
],
"service_account_contents": null,
"service_account_email": null,
"service_account_file": "mykey.json",
"size_gb": null,
"source_image": null,
"source_image_encryption_key": null,
"source_snapshot": {
"changed": true,
"creationTimestamp": "VALUE_SPECIFIED_IN_NO_LOG_PARAMETER",
"failed": false,
"id": "VALUE_SPECIFIED_IN_NO_LOG_PARAMETER",
"kind": "VALUE_SPECIFIED_IN_NO_LOG_PARAMETER",
"labelFingerprint": "VALUE_SPECIFIED_IN_NO_LOG_PARAMETER",
"lastAttachTimestamp": "VALUE_SPECIFIED_IN_NO_LOG_PARAMETER",
"lastDetachTimestamp": "VALUE_SPECIFIED_IN_NO_LOG_PARAMETER",
"name": "VALUE_SPECIFIED_IN_NO_LOG_PARAMETER",
"physicalBlockSizeBytes": "VALUE_SPECIFIED_IN_NO_LOG_PARAMETER",
"selfLink": "VALUE_SPECIFIED_IN_NO_LOG_PARAMETER",
"sizeGb": "VALUE_SPECIFIED_IN_NO_LOG_PARAMETER",
"status": "VALUE_SPECIFIED_IN_NO_LOG_PARAMETER",
"type": "VALUE_SPECIFIED_IN_NO_LOG_PARAMETER",
"users": [
"VALUE_SPECIFIED_IN_NO_LOG_PARAMETER"
],
"zone": "VALUE_SPECIFIED_IN_NO_LOG_PARAMETER"
},
"source_snapshot_encryption_key": null,
"state": "present",
"type": "pd-ssd",
"zone": "us-west2-b"
}
},
"msg": "GCP returned error: {'error': {'code': 400, 'message': \"Invalid value for field 'resource.sourceSnapshot': '********/disks/********'. Unexpected resource collection 'disks'.\", 'errors': [
{'message': \"Invalid value for field 'resource.sourceSnapshot': '********/disks/********'. Unexpected resource collection 'disks'.\", 'domain': 'global', 'reason': 'invalid'}]}}"
}
```
adding `no_log: false` to either or both of `gcp_compute_snapshot` or `gcp_compute_disk` did not seem to have any effect (still obfuscated params, still fails).
Note: strangely, if I run the playbook twice in a row with no changes, it will end up succeeding after the second pass: first run will succeed creating snapshot, but fail making a disk from it (due to aforementioned error). The second run already has an existing snapshot and passes it over (idempotently), registers the snapshot var, and passes to gcp_compute_disk, which that time works. If both tasks (snapshot and disk create) happen in the same ansible-playbook run, the snapshot succeeds, but disk create fails every time.
Also note, even when providing the snapshot via `selfLink` (so it finishes), the `sourceSnapshot` from the result is printed as `VALUE_SPECIFIED_IN_NO_LOG_PARAMETER`, and the `module_args['source_snapshot']` field is shown as `selfLink: VALUE_SPECIFIED_IN_NO_LOG_PARAMETER`.
##### ISSUE TYPE
- Bug Report
##### COMPONENT NAME
gcp_compute_disk
##### ANSIBLE VERSION
```paste below
ansible 2.10.7
config file = /home/scott/src/setup/.ansible.cfg
configured module search path = ['/home/scott/src/setup/lib']
ansible python module location = /home/scott/src/setup/venv/lib/python3.8/site-packages/ansible
executable location = /home/scott/src/setup/venv/bin/ansible
python version = 3.8.8 (tags/v3.8.8:024d8058b0, Mar 2 2021, 18:15:50) [GCC 9.3.0]
```
##### CONFIGURATION
stock
##### OS / ENVIRONMENT
linux
##### STEPS TO REPRODUCE
```yaml
# ...
- name: snapshot_dev_disk
gcp_compute_snapshot:
name: '{{snapname}}'
source_disk:
name: '{{diskdev}}'
# ...
register: snapdisk
- name: create_disk_from_snapshot
gcp_compute_disk:
name: mydisk
type: '{{disktype}}'
source_snapshot: '{{snapdisk}}'
# ...
# ...
```
Contributor guide
Research direction
Start with the gcp_compute_snapshot and gcp_compute_disk tasks in the reproduction playbook, comparing the registered snapshot passed during the same run with the selfLink form. Reproduce the first-run failure and second-run success, then confirm that a registered snapshot is sent as a valid GCP snapshot resource rather than a disk path.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- google-cloud, python
- Domain
- cloud
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100