Open Akasurde opened 4 years ago
From @bucklander on Jul 31, 2020 22:55
FWIW, besides my local macbook, this is also repeatable on an AWX server container:
bash-4.4# cat /etc/redhat-release
CentOS Linux release 8.1.1911 (Core)
bash-4.4# python3 -V
Python 3.6.8
bash-4.4# ansible --version
ansible 2.9.7
config file = /etc/ansible/ansible.cfg
configured module search path = ['/home/awx/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
ansible python module location = /usr/local/lib/python3.6/site-packages/ansible
executable location = /usr/local/bin/ansible
python version = 3.6.8 (default, Nov 21 2019, 19:31:34) [GCC 8.3.1 20190507 (Red Hat 8.3.1-4)]
From @bucklander on Jul 31, 2020 23:23
cc @erjohnso @GoogleCloudPlatform @rambleraptor
FWIW this bug can be resolved by simply changing gcp_storage_object.py#L254 from...
with open(src, "r") as file_obj:
to with open(src, "rb") as file_obj:
This ensures there's no decoding attempt (or subsequent error).
This approach appears similar to download_file
's use of the open
func at gcp_storage_object.py#L243, where it specifically is configured with the b
(binary) mode specifier.
Not only does this resolve the issue with uploading binary files, but the change doesn't appear to harm text uploads. Unsure though if this is a safe strategy overall.
Have opened https://github.com/ansible-collections/google.cloud/pull/268 with a proposed fix, but have no real way to regression test it.
@Akasurde Any idea how to get attention to this?
Until it fixed I stay with Python 2 ansible.cfg
:
[defaults]
interpreter_python = /usr/bin/python2
An alternative approach is to use uri
module and handle authentication / error checking manually: https://github.com/ansible-collections/google.cloud/pull/268#issuecomment-706752987
This error is still persisting in January 2022 more than a year later.
Safe to say at this point the Google Cloud ansible collection should be considered legacy
Safe to say at this point the Google Cloud ansible collection should be considered legacy
There is an incentive to create new products inside Google (to get the promotion). There is no incentive to keep it working.
Still I see new commits in the repository...
I use gcloud
cli + Bash for automation, GCP Ansible modules were unreliable for automation: I need work done, not to waste time debugging Python code of google.collection
(most problems with lack of idempotency).
I think this collection is only a downstream output of https://github.com/GoogleCloudPlatform/magic-modules
downstream output
It explains lack of idempotency, idiomatic for Ansible. They robo-generate code around REST API instead of providing convenient tools. That explains the wide coverage of API & difficulty to fix bugs or add extra functionality beside dumb translation to HTTP call.
Here is on the bug tracker another person recommended to use Google API directly using JSON API key and uri
module. You can list & update resources, building idempotency themselves.
From @bucklander on Jul 31, 2020 22:41
SUMMARY
While using Python3, gcp_storage_object module is unable to upload binary files (and perhaps other file types) without throwing:
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x98 in position 522: invalid start byte
This is possibly related to Ansible python3's explicit string conversion (or not). When using other file types (E.g. simple text files) or just using Python2 with any file type, the problem does not exist.
Below are two example playbooks; One which uploads a gzip tarball file, and another which uploads a simple text file. Each playbook is executed with Python2 and again with Python3.
I'm certainly no expert in file compression or file types, however in my particular case the gzip'd file format seems to cause the issue. I'm also seeing this problem with binary files within regular tarball (no gzip compression). You could also replace the compressed file examples below with seemingly any randomly generated binary file, and the result appears to be the same.
ISSUE TYPE
COMPONENT NAME
gcp_storage_object
ANSIBLE VERSION
CONFIGURATION
OS / ENVIRONMENT
This can be reproduced on a few different systems. Here are a few specific examples:
STEPS TO REPRODUCE
Execute the following example playbooks with a simple, flat text file as well as a tarball.
Example playbook to upload binary file to GCS:
Example playbook to upload text file to GCS:
Run
upload-text-file.yml
using Python 2 (modify Python envs per your system):Run
upload-text-file.yml
using Python 3:Run
upload-bin-file.yml
using Python 2:Run
upload-bin-file.yml
using Python 3:EXPECTED RESULTS
It's expected that all files upload successfully to GCS, regardless of using Python 2, or Python 3 or file type.
ACTUAL RESULTS
Python 2 Text File Upload (successful):
Python 3 Text File Upload (successful):
Python 2 Binary File Upload (successful):
Python 3 Binary File Upload (fails):
Copied from original issue: ansible/ansible#71034