This bug report has Keywords: Regression or TestBlocker.
Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP.

Eli - please reply here on bug 1333746 comment 1. Thanks.

BTW, not sure why this is marked "Regression". IIRC this bug existed "forever".

see https://bugzilla.redhat.com/show_bug.cgi?id=1333746#c3

What exactly should we check re client and server versions?

el6 => 8.4.x 
el7 => 9.2.x
fedora 23 => 9.4.x

(In reply to Jiri Belka from comment #0)
> Description of problem:
> 
> I'm testing migration from 3.6 EL6 with remote DBs (PG 8.x) to 4.0 EL7 while
> still using remote DBs (which I restored from backup).
> 
> Problem is 4.0 supports PG 9.x but I was still original PG 8.x. engine-setup
> from 4.0 should know it needs PG 9.x and should check PG version even for
> remote DBs.

That's a reasonable flow, probably best covered by documentation, depending on how we handle the rest.

RHEV 3.6 docs say to use a RHEL6 machine as a remote database.

> Expected results:
> engine-setup should detect remote DBs are on incompatibile PG version and
> state clearly what should be done

I understand that the main cause for opening this bug is bug 1324882, meaning allow using a remote EnterpriseDB 9.5.

Let's move the discussion there for now.

Closing as duplicate for now. If you think something else is needed on engineering side, before deciding how to continue with bug 1324882, please reopen.

For RHEV 4.0 on RHEL7, we probably want documentation to be updated to say that remote db should be on RHEL7 as well. Feel free to open a doc bug for this. There are probably many other doc changes needed for 4.0, didn't check currently open bugs.

For upstream, I do not think we should do any code change. We support the engine on many different OSes, users can of course install many versions of a remote pg on many different OSes, and I am not aware of actual compatibility complaints. I guess most people that do this either simply use same version.

*** This bug has been marked as a duplicate of bug 1324882 ***

This has nothing to do with that RFE. This is to make sure you are working with the correct version of PGSQL. If we add support for another DB then we can consider other options to check that db.

(In reply to Yaniv Dary from comment #10)
> This has nothing to do with that RFE. This is to make sure you are working
> with the correct version of PGSQL. If we add support for another DB then we
> can consider other options to check that db.

I think it's actually related to that RFE.

Otherwise, we can just require same version. Is this enough?

(In reply to Yedidyah Bar David from comment #11)
> (In reply to Yaniv Dary from comment #10)
> > This has nothing to do with that RFE. This is to make sure you are working
> > with the correct version of PGSQL. If we add support for another DB then we
> > can consider other options to check that db.
> 
> I think it's actually related to that RFE.
> 
> Otherwise, we can just require same version. Is this enough?

We should require 9.2 minimum, since that is what we want to support from now on.

(In reply to Yaniv Dary from comment #12)
> (In reply to Yedidyah Bar David from comment #11)
> > Otherwise, we can just require same version. Is this enough?
> 
> We should require 9.2 minimum, since that is what we want to support from
> now on.

Is it enough to require _same_ version?

If you want to allow > 9.2, backup must be optional. 9.2 pg_dump refuses to backup a newer version db. This was already discussed.

Other than for bug 1324882, I don't see why we can't require _same_ version.

So please choose:

1. Require _same_ version

Or

2. Make backup optional - reopen bug 1333746

Our documentation currently says (1.), code does not enforce it.

(In reply to Yedidyah Bar David from comment #13)
> (In reply to Yaniv Dary from comment #12)
> > (In reply to Yedidyah Bar David from comment #11)
> > > Otherwise, we can just require same version. Is this enough?
> > 
> > We should require 9.2 minimum, since that is what we want to support from
> > now on.
> 
> Is it enough to require _same_ version?
> 
> If you want to allow > 9.2, backup must be optional. 9.2 pg_dump refuses to
> backup a newer version db. This was already discussed.
> 
> Other than for bug 1324882, I don't see why we can't require _same_ version.
> 
> So please choose:
> 
> 1. Require _same_ version

What will happen in fedora installations that use db on CentOS?

> 
> Or
> 
> 2. Make backup optional - reopen bug 1333746
> 
> Our documentation currently says (1.), code does not enforce it.

(In reply to Yaniv Dary from comment #14)
> (In reply to Yedidyah Bar David from comment #13)
> > (In reply to Yaniv Dary from comment #12)
> > > (In reply to Yedidyah Bar David from comment #11)
> > > > Otherwise, we can just require same version. Is this enough?
> > > 
> > > We should require 9.2 minimum, since that is what we want to support from
> > > now on.
> > 
> > Is it enough to require _same_ version?
> > 
> > If you want to allow > 9.2, backup must be optional. 9.2 pg_dump refuses to
> > backup a newer version db. This was already discussed.
> > 
> > Other than for bug 1324882, I don't see why we can't require _same_ version.
> > 
> > So please choose:
> > 
> > 1. Require _same_ version
> 
> What will happen in fedora installations that use db on CentOS?
> 

Do we want to support this?

Not sure. It might work.

oVirt 4.0 beta has been released, moving to RC milestone.

oVirt 4.0 beta has been released, moving to RC milestone.

Not sure why this is High Severity.

Setting needinfo on Yaniv again, still not sure what to do. Current bottom line is comment 13.

Answering again comment 14:

(In reply to Yaniv Dary from comment #14)
> 
> What will happen in fedora installations that use db on CentOS?

I didn't test this, no idea if it works _today_. I think it does not work.

If we decide to require same version, it will not work (at least with the default pg versions supplied in them).

Require same version for now and we can change, if we are required to.

(In reply to Yedidyah Bar David from comment #4)
> BTW, not sure why this is marked "Regression". IIRC this bug existed
> "forever".

based on this removing a regression kw and consequently the blocker flag

Readding blocker since user can easily get to a unsupported state like this.
If you use CentOS 7 you should use the CentOS postgres db version, same for fedora.

Still not sure, but if you say so, who am I to object? Especially since it's a pretty simple change.

Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.

fail, ovirt-engine-setup-plugin-ovirt-engine-common-4.0.2.1-0.1.el7ev.noarch

- client

# psql -V
psql (PostgreSQL) 9.2.15

- server

# psql -h jb-rhevm36.example.com -U remoteengine remoteengine -c "select version();"
                                                      version                                                      
-------------------------------------------------------------------------------------------------------------------
 PostgreSQL 8.4.20 on x86_64-redhat-linux-gnu, compiled by GCC gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-17), 64-bit
(1 row)

While restoring on 4.0 client to a remote DB with PostgreSQL 8.4.20 there is _no_ PG versions check.

...
Preparing to restore:
- Setting credentials for Engine database 'remoteengine'
- Setting credentials for DWH database 'remotedwh'
- Setting credentials for Reports database 'remotereports'
- Unpacking file 'backup'
Restoring:
- Files
- Engine database 'remoteengine'
FATAL: Errors while restoring database remoteengine

Although the code has the diff:

# sed -n '888,912p' /usr/share/ovirt-engine/setup/ovirt_engine_setup/engine_common/database.py
            {
                'key': 'server_version',
                'expected': self._plugin.execute(
                    args=(
                        self.command.get('psql'),
                        '-V',
                    ),
                )[
                    1  # stdout
                ][
                    0  # first line. E.g. on Fedora 23: psql (PostgreSQL) 9.4.8
                ].split(
                    ' '
                )[
                    -1
                ],
                'ok': self._lower_equal,
                'check_on_use': True,
                'needed_on_create': False,
                'error_msg': _(
                    "Postgresql client version is '{expected}', whereas "
                    "the version on {pg_host} is '{current}'. "
                    "Please use a Postgresql server of version '{expected}'."
                ),
            },

Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.

Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.

engine-setup != engine-backup, thus taking back

ok, ovirt-engine-setup-plugin-ovirt-engine-common-4.0.2.1-0.1.el7ev.noarch

...
         Make sure that database can be accessed remotely.
         
          DWH database host [localhost]: jb-rhevm36.example.com
          DWH database port [5432]: 
          DWH database secured connection (Yes, No) [No]: 
          DWH database name [ovirt_engine_history]: remotedwh
          DWH database user [ovirt_engine_history]: remotedwh
          DWH database password: 
[ ERROR ] Cannot connect to DWH database: Postgresql client version is '9.2.15', whereas the version on jb-rhevm36.example.com is '8.4.20'. Please use a Postgresql server of version '9.2.15'.
          DWH database host [localhost]:

Because of incompatibility in major version, now ovirt requires minor version to be the same ?