Do not claim nor test that upgrade works where it does not

Author: hhorak

10/root/usr/share/container-scripts/postgresql/README.md

@@ -208,42 +208,6 @@ container starts it will reset the passwords to the values stored in the
 environment variables.
 
 
-Upgrading database (by switching to newer PostgreSQL image version)
--------------------------------------------------------------------
-
-** Warning! Please, before you decide to do the data directory upgrade, always
-ensure that you've carefully backed up all your data and that you are OK with
-potential manual rollback! **
-
-This image supports automatic upgrade of data directory created by
-the PostgreSQL server version 9.6 (and _only_ this version) - provided by sclorg
-image.  The upgrade process is designed so that you should be able to just
-switch from *image A* to *image B*, and set the `$POSTGRESQL_UPGRADE` variable
-appropriately to explicitly request the database data transformation.
-
-The upgrade process is internally implemented via `pg_upgrade` binary, and for
-that purpose the container needs to contain two versions of PostgreSQL server
-(have a look at `man pg_upgrade` for more info).
-
-For the `pg_upgrade` process - and the new server version, we need to initialize
-a brand new data directory.  That's data directory is created automatically by
-container tooling under /var/lib/pgsql/data, which is usually external
-bind-mountpoint.  The `pg_upgrade` execution is then similar to dump&restore
-approach -- it starts both old and new PostgreSQL servers (within container) and
-"dumps" the old datadir while and at the same time it "restores" it into new
-datadir.  This operation requires a lot of data files copying, so you can decide
-what type of upgrade you'll do by setting `$POSTGRESQL_UPGRADE` appropriately:
-
-**`copy`**  
-       The data files are copied from old datadir to new datadir.  This option has low risk of data loss in case of some upgrade failure.
-
-**`hardlink`**  
-       Data files are hard-linked from old to the new data directory, which brings performance optimization - but the old directory becomes unusable, even in case of failure.
-
-
-Note that because we copy data directory, you need to make sure that you have
-enough space for the copy;  upgrade failure because of not enough space might
-lead to data loss.
 
 
 Extending image

12/root/usr/share/container-scripts/postgresql/README.md

@@ -208,42 +208,6 @@ container starts it will reset the passwords to the values stored in the
 environment variables.
 
 
-Upgrading database (by switching to newer PostgreSQL image version)
--------------------------------------------------------------------
-
-** Warning! Please, before you decide to do the data directory upgrade, always
-ensure that you've carefully backed up all your data and that you are OK with
-potential manual rollback! **
-
-This image supports automatic upgrade of data directory created by
-the PostgreSQL server version 10 (and _only_ this version) - provided by sclorg
-image.  The upgrade process is designed so that you should be able to just
-switch from *image A* to *image B*, and set the `$POSTGRESQL_UPGRADE` variable
-appropriately to explicitly request the database data transformation.
-
-The upgrade process is internally implemented via `pg_upgrade` binary, and for
-that purpose the container needs to contain two versions of PostgreSQL server
-(have a look at `man pg_upgrade` for more info).
-
-For the `pg_upgrade` process - and the new server version, we need to initialize
-a brand new data directory.  That's data directory is created automatically by
-container tooling under /var/lib/pgsql/data, which is usually external
-bind-mountpoint.  The `pg_upgrade` execution is then similar to dump&restore
-approach -- it starts both old and new PostgreSQL servers (within container) and
-"dumps" the old datadir while and at the same time it "restores" it into new
-datadir.  This operation requires a lot of data files copying, so you can decide
-what type of upgrade you'll do by setting `$POSTGRESQL_UPGRADE` appropriately:
-
-**`copy`**  
-       The data files are copied from old datadir to new datadir.  This option has low risk of data loss in case of some upgrade failure.
-
-**`hardlink`**  
-       Data files are hard-linked from old to the new data directory, which brings performance optimization - but the old directory becomes unusable, even in case of failure.
-
-
-Note that because we copy data directory, you need to make sure that you have
-enough space for the copy;  upgrade failure because of not enough space might
-lead to data loss.
 
 
 Extending image

13/root/usr/share/container-scripts/postgresql/README.md

@@ -208,42 +208,6 @@ container starts it will reset the passwords to the values stored in the
 environment variables.
 
 
-Upgrading database (by switching to newer PostgreSQL image version)
--------------------------------------------------------------------
-
-** Warning! Please, before you decide to do the data directory upgrade, always
-ensure that you've carefully backed up all your data and that you are OK with
-potential manual rollback! **
-
-This image supports automatic upgrade of data directory created by
-the PostgreSQL server version 12 (and _only_ this version) - provided by sclorg
-image.  The upgrade process is designed so that you should be able to just
-switch from *image A* to *image B*, and set the `$POSTGRESQL_UPGRADE` variable
-appropriately to explicitly request the database data transformation.
-
-The upgrade process is internally implemented via `pg_upgrade` binary, and for
-that purpose the container needs to contain two versions of PostgreSQL server
-(have a look at `man pg_upgrade` for more info).
-
-For the `pg_upgrade` process - and the new server version, we need to initialize
-a brand new data directory.  That's data directory is created automatically by
-container tooling under /var/lib/pgsql/data, which is usually external
-bind-mountpoint.  The `pg_upgrade` execution is then similar to dump&restore
-approach -- it starts both old and new PostgreSQL servers (within container) and
-"dumps" the old datadir while and at the same time it "restores" it into new
-datadir.  This operation requires a lot of data files copying, so you can decide
-what type of upgrade you'll do by setting `$POSTGRESQL_UPGRADE` appropriately:
-
-**`copy`**  
-       The data files are copied from old datadir to new datadir.  This option has low risk of data loss in case of some upgrade failure.
-
-**`hardlink`**  
-       Data files are hard-linked from old to the new data directory, which brings performance optimization - but the old directory becomes unusable, even in case of failure.
-
-
-Note that because we copy data directory, you need to make sure that you have
-enough space for the copy;  upgrade failure because of not enough space might
-lead to data loss.
 
 
 Extending image

15/root/usr/share/container-scripts/postgresql/README.md

@@ -208,42 +208,6 @@ container starts it will reset the passwords to the values stored in the
 environment variables.
 
 
-Upgrading database (by switching to newer PostgreSQL image version)
--------------------------------------------------------------------
-
-** Warning! Please, before you decide to do the data directory upgrade, always
-ensure that you've carefully backed up all your data and that you are OK with
-potential manual rollback! **
-
-This image supports automatic upgrade of data directory created by
-the PostgreSQL server version 13 (and _only_ this version) - provided by sclorg
-image.  The upgrade process is designed so that you should be able to just
-switch from *image A* to *image B*, and set the `$POSTGRESQL_UPGRADE` variable
-appropriately to explicitly request the database data transformation.
-
-The upgrade process is internally implemented via `pg_upgrade` binary, and for
-that purpose the container needs to contain two versions of PostgreSQL server
-(have a look at `man pg_upgrade` for more info).
-
-For the `pg_upgrade` process - and the new server version, we need to initialize
-a brand new data directory.  That's data directory is created automatically by
-container tooling under /var/lib/pgsql/data, which is usually external
-bind-mountpoint.  The `pg_upgrade` execution is then similar to dump&restore
-approach -- it starts both old and new PostgreSQL servers (within container) and
-"dumps" the old datadir while and at the same time it "restores" it into new
-datadir.  This operation requires a lot of data files copying, so you can decide
-what type of upgrade you'll do by setting `$POSTGRESQL_UPGRADE` appropriately:
-
-**`copy`**  
-       The data files are copied from old datadir to new datadir.  This option has low risk of data loss in case of some upgrade failure.
-
-**`hardlink`**  
-       Data files are hard-linked from old to the new data directory, which brings performance optimization - but the old directory becomes unusable, even in case of failure.
-
-
-Note that because we copy data directory, you need to make sure that you have
-enough space for the copy;  upgrade failure because of not enough space might
-lead to data loss.
 
 
 Extending image

src/root/usr/share/container-scripts/postgresql/README.md

@@ -208,6 +208,7 @@ container starts it will reset the passwords to the values stored in the
 environment variables.
 
 
+{% if spec.prod == 'rhel7' or spec.prod == 'centos7' %}
 Upgrading database (by switching to newer PostgreSQL image version)
 -------------------------------------------------------------------
 
@@ -244,6 +245,7 @@ what type of upgrade you'll do by setting `$POSTGRESQL_UPGRADE` appropriately:
 Note that because we copy data directory, you need to make sure that you have
 enough space for the copy;  upgrade failure because of not enough space might
 lead to data loss.
+{% endif %}
 
 
 Extending image

test/run_test

@@ -663,11 +663,11 @@ $volume_options
 run_upgrade_test ()
 {
   local ret=0
-    # Do not run on Fedora or RHEL8 until the upgrade script
+    # Do not run on Fedora or RHEL8+ until the upgrade script
     # is fixed for non-SCL use cases
-    { [ "${OS}" == "fedora" ] || [ "${OS}" == "rhel8" ]; } && return 0
+    { [ "${OS}" != "centos7" ] && [ "${OS}" != "rhel7" ]; } && return 0
 
-    local upgrade_path="none 9.2 9.4 9.5 9.6 10 12 13 15 none" prev= act=
+    local upgrade_path="none 9.2 9.4 9.5 9.6 10 12 13 none" prev= act=
     for act in $upgrade_path; do
         if test "$act" = $VERSION; then
             break