Bug 1654068 - The RHV db dump in Log Collector is in "ASCII text" format
Summary: The RHV db dump in Log Collector is in "ASCII text" format
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-log-collector
Version: 4.2.7
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ovirt-4.3.5
: ---
Assignee: Douglas Schilling Landgraf
QA Contact: Petr Kubica
URL:
Whiteboard:
Depends On: 1656278 1658571 1658939
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-28 01:07 UTC by Gajanan
Modified: 2019-08-28 13:17 UTC (History)
10 users (show)

Fixed In Version: sos-3.7-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-08-23 09:54:06 UTC
oVirt Team: Integration
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 3736571 None None None 2018-12-05 05:54:29 UTC

Description Gajanan 2018-11-28 01:07:19 UTC
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.

Comment 1 Douglas Schilling Landgraf 2018-11-29 03:07:27 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?

Comment 2 Marina Kalinin 2018-11-29 19:18:41 UTC
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

Comment 6 Yedidyah Bar David 2018-12-04 11:29:18 UTC
https://github.com/sosreport/sos/pull/1497

Comment 7 nijin ashok 2018-12-04 12:06:15 UTC
(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.

Comment 8 Yedidyah Bar David 2018-12-05 07:26:54 UTC
(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.

Comment 9 Yedidyah Bar David 2018-12-05 11:07:43 UTC
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.)

Comment 10 Yedidyah Bar David 2018-12-06 09:24:46 UTC
Will post a patch to require newer version of sos once we know what this version is.

Comment 14 Sandro Bonazzola 2019-01-21 08:28:25 UTC
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.

Comment 16 Sandro Bonazzola 2019-02-18 07:54:48 UTC
Moving to 4.3.2 not being identified as blocker for 4.3.1.

Comment 17 Sandro Bonazzola 2019-03-12 13:36:08 UTC
sos fix is targeted RHEL 7.7, pushing this to 4.3.5.

Comment 18 Sandro Bonazzola 2019-07-11 07:02:14 UTC
Re-targeting to 4.3.6 not being identified as blocker for 4.3.5.

Comment 19 Yedidyah Bar David 2019-07-14 08:00:59 UTC
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.

Comment 20 Sandro Bonazzola 2019-08-23 09:54:06 UTC
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

Comment 21 Daniel Gur 2019-08-28 13:13:34 UTC
sync2jira

Comment 22 Daniel Gur 2019-08-28 13:17:47 UTC
sync2jira


Note You need to log in before you can comment on or make changes to this bug.