[ovirt-users] upgrade to 4.1

[Yedidyah Bar David]

On Sun, Apr 23, 2017 at 2:53 PM, Fabrice Bacchella
<fabrice.bacchella at orange.fr> wrote:
>
>> Le 23 avr. 2017 à 07:59, Yedidyah Bar David <didi at redhat.com> a écrit :
>>
>>
>
>> The main reason we require this is for pg_dump/pg_restore which are ran
>> during setup/rollback (if needed). pg_dump can't know for sure that all
>> the changes in the db were done using a client of its own version (that
>> is, current machine usually), and if indeed a newer client was used, it
>> might have used features that pg_dump of the lower version doesn't know
>> how to back up (and especially pg_restore does not know how to restore).
>> See also [1]. I seem to have tested there (can't remember anymore, see
>> comment 13) 9.2 client with 9.5 server and it didn't work. pg_dump(1)
>> manpage says:
>>
>>       Because pg_dump is used to transfer data to newer versions of
>>       PostgreSQL, the output of pg_dump can be expected to load into
>>       PostgreSQL server versions newer than pg_dump's version.  pg_dump can
>>       also dump from PostgreSQL servers older than its own version.
>>       (Currently, servers back to version 7.0 are supported.) However,
>>       pg_dump cannot dump from PostgreSQL servers newer than its own major
>>       version; it will refuse to even try, rather than risk making an invalid
>>       dump. Also, it is not guaranteed that pg_dump's output can be loaded
>>       into a server of an older major version — not even if the dump was
>>       taken from a server of that version. Loading a dump file into an older
>>       server may require manual editing of the dump file to remove syntax not
>>       understood by the older server. Use of the --quote-all-identifiers
>>       option is recommended in cross-version cases, as it can prevent
>>       problems arising from varying reserved-word lists in different
>>       PostgreSQL versions.
>>
>
> I don't get it, but I don't know pg so I might be wrong.
>
> You have a client application (like ovirt) written using features from V1 of pg.

Right.

>
> It's running on a server where version V2 is installing. For good reasons, V2 >= V1 is needed.

Indeed.

>
> The server is running a version V3. Again V3 >= V1 is needed.   Except for major version, does V3 => V2 is really needed ?

For oVirt itself, no.

>
> And for backup the problem is the same. It must probably know every features used in the application (so again being V1 or more). Why does it needs to match both V2 and V3 ?  It will probably fits V2 is installation is the same. But that not mandatory. In a java application, the client library might be a jar provided by the application and pg_dump a tool installed with native os packaging. But how can complain against V3 ?

pg_dump is indeed a tool installed from the OS. I copied above the relevant
part of its manpage - if you think it does a wrong thing, perhaps better
continue the discussion on postgresql lists.

For our concern, the only relevant fact is that we decided to backup the
db using pg_dump during setup, and to restore it on rollback. If you want
to make this backup optional, please open an RFE, as already requested, and
we can discuss this there.

>
> But with ovirt we have V1=V2=V3,

Not exactly. Using your terminology, we have V1<=V2, V2=V3.

> even for for patch level (9.4.8 against 9.4.11). What kind of feature that ovirt don't know about might be missing ? I don't think ovirt might know about any 9.4 since you talked about version 9.2 as the official supported version.

At the time, oVirt didn't check versions at all, and so failed on a
certain combination, and it was decided to require V2=V3, as a simple
and effective solution. This was also specifically discussed there,
as you can see for yourself, open to the public for review/comments.
Check especially comments 9 to 19 (in bz 1331168).

If you think we need a more delicate test, please open an RFE,
preferably providing the details I suggested that should be considered
for one.

Also please recall that you have a third, very simple, IMHO, option.
If for any reason you decided to have your server with version V3,
simply install V3 on your client machine (the oVirt engine). This
will be simple and solve all problems. If your concern is that the
OS does not supply pg V3, then it applies also to the OS of the
server. If that is a different OS, you are welcome to port oVirt
engine to that OS so you can have all you want at once.

You also have a fourth option - patch oVirt to not check for the
version, by reverting the patch that introduced this check (might
require a bit more work than "git revert", but not much):

https://gerrit.ovirt.org/59941

Of course, this will essentially be a fork, and I'd personally not
recommend it. But it's still an option.

Best,
-- 
Didi