i think i found the significant differences between our ec2 and gcp instances. - on ec2: - zstandard **0.11.1** is installed - `requests.utils.DEFAULT_CA_BUNDLE_PATH` is not used because the `requests` module is not installed for python3 - `c:\mozilla-build\python3\lib\site-packages\certifi\cacert.pem` does not exist. - on gcp: - `zstandard` **0.12.0** was installed - latest `zstandard` has a dependency on latest `requests` which has a dependency on latest `certifi` - `requests.utils.DEFAULT_CA_BUNDLE_PATH` is set by `certifi` to `c:\mozilla-build\python3\lib\site-packages\certifi\cacert.pem` (which exists). for now, i am rolling back zstandard to 0.11.1 on gcp. however, i think this issue is warning us that if we upgrade to zstandard 0.12.0 in future, without understanding the certificate verification issue there, we will see this problem again. this whole comment can be ignored if the builds at https://treeherder.mozilla.org/#/jobs?repo=try&revision=699bdf2 go red. they are using zstandard 0.11.1 so if they don't go green, then the zstandard version had nothing to do with the CERTIFICATE_VERIFY_FAILED issue.
Bug 1582726 Comment 5 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
i think i found the significant differences between our ec2 and gcp instances. - on ec2: - zstandard **0.11.1** is installed - `requests.utils.DEFAULT_CA_BUNDLE_PATH` is [not used](https://tools.taskcluster.net/groups/M_tx29JWSaK1CiU3Vn__pQ/tasks/M_tx29JWSaK1CiU3Vn__pQ/runs/0/logs/public%2Flogs%2Flive.log) because the `requests` module is not installed for python3 - `c:\mozilla-build\python3\lib\site-packages\certifi\cacert.pem` does not exist. - on gcp: - `zstandard` **0.12.0** was installed - latest `zstandard` has a dependency on latest `requests` which has a dependency on latest `certifi` - `requests.utils.DEFAULT_CA_BUNDLE_PATH` is set by `certifi` to `c:\mozilla-build\python3\lib\site-packages\certifi\cacert.pem` (which exists). for now, i am rolling back zstandard to 0.11.1 on gcp. however, i think this issue is warning us that if we upgrade to zstandard 0.12.0 in future, without understanding the certificate verification issue there, we will see this problem again. this whole comment can be ignored if the builds at https://treeherder.mozilla.org/#/jobs?repo=try&revision=699bdf2 go red. they are using zstandard 0.11.1 so if they don't go green, then the zstandard version had nothing to do with the CERTIFICATE_VERIFY_FAILED issue.
i think i found the significant differences between our ec2 and gcp instances. - on ec2: - `zstandard` **0.11.1** is installed - `requests.utils.DEFAULT_CA_BUNDLE_PATH` is [not used](https://tools.taskcluster.net/groups/M_tx29JWSaK1CiU3Vn__pQ/tasks/M_tx29JWSaK1CiU3Vn__pQ/runs/0/logs/public%2Flogs%2Flive.log) because the `requests` module is not installed for python3 - `c:\mozilla-build\python3\lib\site-packages\certifi\cacert.pem` does not exist. - on gcp: - `zstandard` **0.12.0** was installed - latest `zstandard` has a dependency on latest `requests` which has a dependency on latest `certifi` - `requests.utils.DEFAULT_CA_BUNDLE_PATH` is set by `certifi` to `c:\mozilla-build\python3\lib\site-packages\certifi\cacert.pem` (which exists). for now, i am rolling back zstandard to 0.11.1 on gcp. however, i think this issue is warning us that if we upgrade to zstandard 0.12.0 in future, without understanding the certificate verification issue there, we will see this problem again. this whole comment can be ignored if the builds at https://treeherder.mozilla.org/#/jobs?repo=try&revision=699bdf2 go red. they are using zstandard 0.11.1 so if they don't go green, then the zstandard version had nothing to do with the CERTIFICATE_VERIFY_FAILED issue.
i think i found the significant differences between our ec2 and gcp instances. - on ec2: - `zstandard` **0.11.1** is installed - `requests.utils.DEFAULT_CA_BUNDLE_PATH` is [not used](https://tools.taskcluster.net/groups/M_tx29JWSaK1CiU3Vn__pQ/tasks/M_tx29JWSaK1CiU3Vn__pQ/runs/0/logs/public%2Flogs%2Flive.log) because the `requests` module is not installed for python3 - `c:\mozilla-build\python3\lib\site-packages\certifi\cacert.pem` does not exist. - on gcp: - `zstandard` **0.12.0** was installed - latest `zstandard` has a dependency on latest `requests` which has a dependency on latest `certifi` - `requests.utils.DEFAULT_CA_BUNDLE_PATH` is set by `certifi` to `c:\mozilla-build\python3\lib\site-packages\certifi\cacert.pem` (which exists). for now, i am [rolling back](https://github.com/mozilla-releng/OpenCloudConfig/commit/7a0b19e) zstandard to 0.11.1 on gcp. however, i think this issue is warning us that if we upgrade to zstandard 0.12.0 in future, without understanding the certificate verification issue there, we will see this problem again. this whole comment can be ignored if the builds at https://treeherder.mozilla.org/#/jobs?repo=try&revision=699bdf2 go red. they are using zstandard 0.11.1 so if they don't go green, then the zstandard version had nothing to do with the CERTIFICATE_VERIFY_FAILED issue.