Bug 1753587
| Summary: | https://build.gluster.org/job/compare-bug-version-and-git-branch/41059/ fails for public BZ | ||
|---|---|---|---|
| Product: | [Community] GlusterFS | Reporter: | Nithya Balachandran <nbalacha> |
| Component: | project-infrastructure | Assignee: | bugs <bugs> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | urgent | Docs Contact: | |
| Priority: | urgent | ||
| Version: | 6 | CC: | bugs, dkhandel, gluster-infra, mscherer, pasik, ykaul |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-02-27 06:04:27 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Nithya Balachandran
2019-09-19 11:09:51 UTC
The error seems to be related to some missing Python package: ImportError: No module named 'requests.packages.urllib3' Maybe these additional RPM needs to be installed: - python-requests.noarch : HTTP library, written in Python, for human beings - python-urllib3.noarch : Python HTTP library with thread-safe connection pooling and file post With those RPMs installed, the package requests.packages.urllib3 can be imported. python-requests is installed, and so is python-urllib3. But it seems there was some fluck and we have a faulty package. I will fix. ok, so I suspect it might have been partially due to a mix of pip package (for github3-py) and the rpms. let's see if my cleanup is working. so, now we face a interesting issue, gerrit produce invalid json: ~ $ curl -s "https://review.gluster.org/changes/glusterfs~master~I4fbb5c924fb3a144e415d2368126b784dde760ea/revisions/1/commit" |head -n 5 )]}' { "commit": "13f8432734f8fd3fe59f05a48d297a7e72c33301", "parents": [ { Why, I have no idea. We flushed caches, etc just in case, and I will look at the DB side, but maybe we will need to restart gerrit quickly before I get to dig the source code. And this issue is not even persistent. We are getting random invalid JSON when using gerrit API and sometimes not. I think Gerrit does it on purpose. Quite a while ago I have used Gerrit(Hub) and scripts needed to drop the 1st line 'magic' value before parsing the response. From https://review.gluster.org/Documentation/rest-api.html#output : To prevent against Cross Site Script Inclusion (XSSI) attacks, the JSON response body starts with a magic prefix line that must be stripped before feeding the rest of the response body to a JSON parser: )]}' [ ... valid JSON ... ] mhh, then why did it broke suddenly ? ok, so that explain the cleaned_output line in the code. So I guess we are back on the drawing board to figure why it break now I can't reproduce much, so I have left debugging output and will wait until next run (In reply to M. Scherer from comment #10) > now I can't reproduce much, so I have left debugging output and will wait > until next run It just happened to me several times, so it's certainly happening. See https://build.gluster.org/job/bugzilla-post/16502/console ok, so I am quite puzzled. The request made with python fail, but not with curl. But at least I can see why it give weird result. So it seems the issue is that request do convert ~ to %7E and curl doesn't. After looking for a while, it seems that pip did decide to erase some of the rpm provided file, thus result in a weridly almost working mix, that broke when i tried to fix. I did clean everything and now, it should be working. We still need to make sure that github3-py do not interfere (ideally, the less we use pip, the better, cause this result into this kind of problem :/), but for now, I think thing should work. This seems to be working fine till now. Thank you, Michael. Closing it. |