(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

https://github.com/sosreport/sos/pull/1497

(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