Bug 1654068
| Summary: | The RHV db dump in Log Collector is in "ASCII text" format | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Gajanan <gchakkar> |
| Component: | ovirt-log-collector | Assignee: | Douglas Schilling Landgraf <dougsland> |
| Status: | CLOSED ERRATA | QA Contact: | Petr Kubica <pkubica> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 4.2.7 | CC: | bcholler, didi, gchakkar, lsvaty, mkalinin, mmartinv, mperina, nashok, rbarry, usurse |
| Target Milestone: | ovirt-4.3.5 | Keywords: | Tracking |
| Target Release: | --- | Flags: | lsvaty:
testing_plan_complete-
|
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | sos-3.7-1.el7 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-08-23 09:54:06 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Integration | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1656278, 1658571, 1658939 | ||
| Bug Blocks: | |||
|
Description
Gajanan
2018-11-28 01:07:19 UTC
(In reply to Gajanan from comment #0) > Description of problem: > > Whenever we collect ovirt-log-collector from RHV, the dump in it is in > "ASCII text" format, so it cannot be restored. > > ~~~ > $ file pgdump-scl-rh-postgresql95.tar > pgdump-scl-rh-postgresql95.tar: ASCII text, with very long lines > ~~~ > > > Need to fix this issue. I am investigating, couldn't reproduce the report so far # file pgdump-scl-rh-postgresql95.tar pgdump-scl-rh-postgresql95.tar: POSIX tar archive From sosreport/installed-rpms I see: ovirt-log-collector-4.2.7-1.el7ev.noarch redhat-release-server-7.6-4.el7.x86_64 rhvm-4.2.7.5-0.1.el7ev.noarch I have tested against: rhvm-4.2.7.5-0.1.el7ev.noarch rhvm-4.2.8-0.1.el7ev.noarch Could we collect output of ovirt-log-collector -vvv? As a workaround, it is possible to gather the db_dump from customer environment in the following way: # source /etc/ovirt-engine/engine.conf.d/10-setup-database.conf# PGPASSWORD="$ENGINE_DB_PASSWORD" scl enable rh-postgresql95 -- pg_dump -h localhost -U $ENGINE_DB_USER -w -f /tmp/engine.db-$(date +%F_%T:%S).dump -F t $ENGINE_DB_DATABASE (In reply to Yedidyah Bar David from comment #6) > https://github.com/sosreport/sos/pull/1497 Thanks, Didi. So it was because of https://github.com/sosreport/sos/commit/33c6611c2a6669dc3b04e76b7013d577fe39cff6 . So any DB dump which is having a size greater than 25 MB will be having the issue. A workaround will be to collect using ovirt-log-collector --log-size=0. I will document this in a KCS. (In reply to nijin ashok from comment #7) > (In reply to Yedidyah Bar David from comment #6) > > https://github.com/sosreport/sos/pull/1497 > > Thanks, Didi. So it was because of > https://github.com/sosreport/sos/commit/ > 33c6611c2a6669dc3b04e76b7013d577fe39cff6 . > Indeed > So any DB dump which is having a size greater than 25 MB will be having the > issue. > Indeed > A workaround will be to collect using ovirt-log-collector --log-size=0. I > will document this in a KCS. Correct. Thanks. Moving current bug to NEW and adding sos bug as dependency. In principle we can close current. Reproduction/Verification steps:
1. Make sure your engine db is large enough, so that its dump is > 25MiB. I did this with:
su - postgres
scl enable rh-postgresql95 bash
psql engine
create table test1(a varchar(512))
alter table test1 owner to engine
\q
a=$(printf 'a%.0s' $(seq 511)); for i in $(seq 50000); do echo "insert into test1 values('$a');"; done | psql engine
Obviously, there are other means (such as creating many VMs/Disks/NICs/etc. and/or causing lots of errors so that the audit_log is filled).
2. ovirt-log-collector
This creates an archive /tmp/sosreport-LogCollector-$TIMESTAMP.tar.xz
3. cd /tmp; tar xpf sosreport-LogCollector-$TIMESTAMP.tar.xz
4. cd sosreport-LogCollector-$TIMESTAMP
5. cd log-collector-data
6. tar xpf postgresql-sosreport-*.tar.xz
7. cd to generated directory postgresql-sosreport-*
8. cd sos_commands/postgresql
9. check the files there (e.g. with ls -l, 'file', or 'less < file').
On a broken build of sos (e.g. sos-3.6-11), the size will be around 25MiB, 'file' will say it's ASCII text, 'less' will show something from the middle of a pg dump.
On a fixed build, the size will be larger, 'file' will say it's a tar file, 'less' will show tar "garbage" (header with binary data etc.)
Will post a patch to require newer version of sos once we know what this version is. re-targeting to 4.3.1 since this BZ has not been proposed as blocker for 4.3.0. If you think this bug should block 4.3.0 please re-target and set blocker flag. Moving to 4.3.2 not being identified as blocker for 4.3.1. sos fix is targeted RHEL 7.7, pushing this to 4.3.5. Re-targeting to 4.3.6 not being identified as blocker for 4.3.5. Moving to VERIFIED. Current bug is actually only a tracker for a RHEL bug in sos, and all dependent bugs are already verified. Last one not already closed is for RHEL 7.7, which should already be released by RHV 4.3.5 release time. Closing this with sos errata already shipped. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2019:2295 sync2jira sync2jira |