Bug 1194252
| Summary: | Remove binary data dumping on uploads in server_calls.log | ||
|---|---|---|---|
| Product: | [Retired] Pulp | Reporter: | Irina Gulina <igulina> |
| Component: | puppet-support | Assignee: | pulp-bugs |
| Status: | CLOSED UPSTREAM | QA Contact: | pulp-qe-list |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | CC: | bmbouter, cduryee, igulina, rbarlow |
| Target Milestone: | --- | Keywords: | Triaged |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-02-28 23:25:01 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
Irina Gulina
2015-02-19 12:10:07 UTC
The URL being submitted to is content/uploads/<uuid>/ so it makes sense that the payload would be binary data. That is the binary data of the uploaded puppet module. I would expect that same from rpm binary data or any kind of binary content being uploaded. It looks a little strange, but it seems correct to me. Besides that the data looks strange is there some other correctness problem? Can't a log file contain a binary code? and if a pulp-server would dump a binary logs to jounralctl? I think this example is really about binary 'data' not binary 'code'. Those are different terms. Yes log files can contain binary or non-binary data. What does pulp-server have to do with this? The log name is server_calls.log, but its really written by the client as it makes calls to the server. The server isn't involved with that log at all. Also I don't think a proper logger (ie: journalctl or syslog) is involved in writing the server_calls.log file. It's literally just written out to a file as calls occur to the server. This is my understanding. It doesn't matter much anyway since the logger just logs the data as it receives it regardless of if it is binary data or not. I don't think the question I asked was answered. I'll re-ask: It looks a little strange, but it seems correct to me. Besides that the data looks strange because its binary data, is there some other correctness problem? If you consider this behaviour correct, close this bug, please. Thank you. If not possible to filter the binary data, please consider logging it in a terminal- and user-friendly way e.g. in form of base64-encoded chunks I agree that logging binary data is not particularly helpful or useful. In fact, the syslog RFCs specify that log data must be presented in UTF-8 or ASCII, so there is a precedent for log data being for human parsing and not for machine parsing. On an implementation note, it wouldn't be hard to just remove the spots that log binary data (should only be uploads, right?) and replace that data with <binary data>, or something along those lines. Also, I don't view this as an RFE. I think it's a defect. Story 145 [0] has a lot to do with this request. Once that is completed then the only way you would experience this is if you did an upload with pulp-admin and had -vv set. I expect the server_calls.log to log only with -vv. I think of the -vv logger as logging the URL, headers, and request body. Is having the binary data present such a problem that we should deviate from this consistency? Also perhaps seeing the binary data could be useful in some situation. Ensuring that log data adheres to UTF-8 or ASCII would be good for us to check, but that is a separate issue. [0]: https://pulp.plan.io/issues/145 Hi Brian, I think Story #145 will make this BZ even more important to fix. If you send binary data into a console it becomes corrupted. You can try this by catting /dev/urandom or a large binary file. I think the server calls are reasonable to log when they are textual data (and 99% of our calls are). After some reading, I agree that logging binary data is not useful. It's encoded as UTF-8 and can't usefully be compared against the original data. Given that ISOs could be huge files it could be bad if we don't stop server_calls.log from logging binary data. Moved to https://pulp.plan.io/issues/705 |