[postgresql] Collect data for postgreSQL from RHSCL

[pmoravec]

Collect postgreSQL data also when postgreSQL is installed from
Red Hat Software Collections.

Resolves: #1090

Signed-off-by: Pavel Moravec pmoravec@redhat.com

---

Please place an 'X' inside each '[]' to confirm you adhere to our Contributor Guidelines

• Is the commit message split over multiple lines and hard-wrapped at 72 characters?
• Is the subject and message clear and concise?
• Does the subject start with [plugin_name] if submitting a plugin patch or a [section_name] if part of the core sosreport code?
• Does the commit contain a Signed-off-by: First Lastname email@example.com?

[pmoravec]

There was an idea to have a child class of RedHatPostgreSQL that would bring even simpler patch. But that would be against the principle that sosreport executes exactly one class from each plug-in (cf. with https://github.com/sosreport/sos/blob/master/sos/policies/__init__.py#L239, breaking this would allow two plugins of "postgresql" name, quite confusing).

[dougsland]

The patch looks good to me. Just one question, isn't a good idea to check if rh-postgresql95-postgresql-server is installed as you did in line 119?

[pmoravec]

This class can be enabled either by:

• presence of either postgresql or rh-postgresql95-postgresql-server package (plugin/class is enabled by default when a package from packages is present, or when a file from files is present) - see https://github.com/sosreport/sos/pull/1118/files#diff-93be9976582cadc41ed1cec376205196R116 and https://github.com/sosreport/sos/blob/master/sos/plugins/__init__.py#L99-L102 . In this case, and if postgresql isnt installed, we can deduce rh-postgresql95-postgresql-server is installed.
• or this class can be enabled manually, e.g. via cmdline option -o postgres. Then potentially neither package can be present. In that case, we should rather take default postgres data as the default option. So we should rather revert the test (use scl commands only when scl installed, otherwise default to normal postgres).

The difference is imho small, leaving on @bmr-cymru opinion if it makes sense to improve it that way.

[dougsland]

@pmoravec right, what happens if we have both installed? Looks like, it will use the postgresql, which I believe is not correct. A possible solution is invert the if logic, like if self.is_installed('rh-postgresql95-postgresql-server') else postgresql. @sandrobonazzola

cat /etc/redhat-release

CentOS Linux release 7.4.1708 (Core)

[root@localhost ~]# rpm -qa | grep -i postgres
postgresql-jdbc-9.2.1002-5.el7.noarch
rh-postgresql95-postgresql-libs-9.5.7-2.el7.x86_64
postgresql-server-9.2.23-1.el7_4.x86_64
rh-postgresql95-scldevel-2.2-2.el7.x86_64
postgresql-9.2.23-1.el7_4.x86_64
rh-postgresql95-postgresql-server-9.5.7-2.el7.x86_64
rh-postgresql95-runtime-2.2-2.el7.x86_64
postgresql-libs-9.2.23-1.el7_4.x86_64
collectd-postgresql-5.7.2-1.el7.x86_64
rh-postgresql95-postgresql-9.5.7-2.el7.x86_64

[bmr-cymru]

Eh, this does not look right to me.

Having separate pghome and sclpghome plugin options is a bit of an ugly hack, and not very nice for users to try to understand.

I think it would be better to revive the SCLPluign mixin concept from PR #900 than to attempt to solve this in an ad-hoc and plugin specific fashion.

[bmr-cymru]

Let's try to make this work with SCLPlugin if we can - I don't like the proliferation of hacks that are starting to accumulate here.

[bmr-cymru]

Eh, this does not look right to me.

Having separate pghome and sclpghome plugin options is a bit of an ugly hack, and not very nice for users to try to understand.

I think it would be better to revive the SCLPluign mixin concept from PR #900 than to attempt to solve this in an ad-hoc and plugin specific fashion.

[sandrobonazzola]

So did this miss sos 3.5?

[pmoravec]

It is included in 3.5 via commits 947e708 and 62d6435.

So I am closing this PR.