ansible-collections / ansible-collections/google.cloud

gcp_compute_disk doesn't work with a registered gcp_compute_snapshot source

Open
#396 5 comments 0 reactions 0 assignees View on GitHub
stale
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.