Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Server migrator to 15.4 #4704

Merged
merged 15 commits into from
Jun 1, 2022
Merged
Show file tree
Hide file tree
Changes from 12 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 7 additions & 7 deletions spacewalk/package/spacewalk.spec
Original file line number Diff line number Diff line change
Expand Up @@ -104,7 +104,7 @@ Provides: spacewalk-db-virtual = %{version}-%{release}
Requires: spacewalk-backend-sql-postgresql
Requires: spacewalk-java-postgresql
Requires: perl(DBD::Pg)
%if 0%{?suse_version}
%if 0%{?suse_version} || 0%{?is_opensuse}
%if 0%{?sle_version} >= 150400
Requires: postgresql14
Requires: postgresql14-contrib
Expand All @@ -118,12 +118,12 @@ Requires: postgresql13-contrib
Conflicts: postgresql-implementation >= 14
Conflicts: postgresql-contrib-implementation >= 14
%endif # if sle_version >= 150400
%else # not suse_version
Requires: postgresql >= 12
Requires: postgresql-contrib >= 12
# we do not support postgresql versions > 13.x yet
Conflicts: postgresql >= 14
Conflicts: postgresql-contrib >= 14
%else # not suse_version or opensuse
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not for this PR, but I am wondering about this part... @sbluhm does it mean the installations on top of EL8 are still using PostgreSQL12?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

EL is using 13.5. Does the logic force a different version? (if it does, then it's not working :) )

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the code forced to use a postgres version between 12 and 14, I just changed it from 13 to 15 (15 is not released yet).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK. Thanks.

@sbluhm well, on paper EL should use the same version Uyuni uses for openSUSE.

Until now it was OK, because we were based on Leap 15.3 and PostgreSQL 13. But Uyuni 2022.06 will change to Leap 15.4 and PostgreSQL 14.

EL8 should be working, as I don't recall we are using anything specific that only works for PostgreSQL 14. But now that we have it on Uyuni for Leap, that could change.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In fact, it could be Uyuni on EL won't start again if it's not switched to PostgreSQL 14.

From the SUSE Manager 4.3 release notes I am copying this to Uyuni 2022.06:

To prevent inconsistent configurations and data on upgrade or update, Uyuni 2022.06 refuse to start until the database migration from PostgreSQL 13 to PostgreSQL 14 has been completed successfully.

Not sure if that check works for EL as well, but FMPOV, this should be reviewed and EL should use PosgreSQL 14 as well.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, let me check what I can do.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we will have postgresql14

Requires: postgresql >= 13
Requires: postgresql-contrib >= 13
# we do not support postgresql versions > 14.x yet
Conflicts: postgresql >= 15
Conflicts: postgresql-contrib >= 15
%endif # if suse_version

%description postgresql
Expand Down
1 change: 1 addition & 0 deletions susemanager/bin/pg-migrate-x-to-y.sh
Original file line number Diff line number Diff line change
Expand Up @@ -199,6 +199,7 @@ else
fi

cp /var/lib/pgsql/data-pg$OLD_VERSION/pg_hba.conf /var/lib/pgsql/data
cp /var/lib/pgsql/data-pg${OLD_VERSION}/postgresql.conf /var/lib/pgsql/data/
chown postgres:postgres /var/lib/pgsql/data/*

echo "$(timestamp) Starting PostgreSQL service..."
Expand Down
39 changes: 28 additions & 11 deletions susemanager/bin/server-migrator.sh
Original file line number Diff line number Diff line change
Expand Up @@ -19,27 +19,44 @@ echo
read -n 1 -s -r -p "Press any key to start the migration or CTRL+C to cancel...";
echo

NEW_VERSION_ID=15.4

CHECK_OS=$(cat /etc/os-release | grep PRETTY_NAME)

if [[ ${CHECK_OS} != *"openSUSE Leap"* ]]; then
echo "Please check your OS. openSUSE Leap is needed "
exit -1
fi

spacewalk-service stop
rm -rf /etc/zypp/repos.d.old
mv /etc/zypp/repos.d /etc/zypp/repos.d.old
mkdir /etc/zypp/repos.d
zypper ar -n "Main Repository" http://download.opensuse.org/distribution/leap/15.3/repo/oss repo-oss
zypper ar -n "Main Update Repository" http://download.opensuse.org/update/leap/15.3/oss repo-update
zypper ar -n "Non-OSS Repository" http://download.opensuse.org/distribution/leap/15.3/repo/non-oss repo-non-oss
zypper ar -n "Update Repository (Non-Oss)" http://download.opensuse.org/update/leap/15.3/non-oss/ repo-update-non-oss
zypper ar -n "Main Repository" http://download.opensuse.org/distribution/leap/${NEW_VERSION_ID}/repo/oss repo-oss
zypper ar -n "Main Update Repository" http://download.opensuse.org/update/leap/${NEW_VERSION_ID}/oss repo-update
zypper ar -n "Non-OSS Repository" http://download.opensuse.org/distribution/leap/${NEW_VERSION_ID}/repo/non-oss repo-non-oss
zypper ar -n "Update Repository (Non-Oss)" http://download.opensuse.org/update/leap/${NEW_VERSION_ID}/non-oss/ repo-update-non-oss
zypper ar -n "Uyuni Server Stable" https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable/images/repo/Uyuni-Server-POOL-x86_64-Media1/ uyuni-server-stable
zypper ar -n "Update repository wiht updates from SUSE Linux Enterprise 15" http://download.opensuse.org/update/leap/15.3/sle repo-sle-update
zypper ar -n "Update repository of openSUSE Backports" http://download.opensuse.org/update/leap/15.3/backports/ repo-backports-update
zypper ar -n "Update repository wiht updates from SUSE Linux Enterprise" http://download.opensuse.org/update/leap/${NEW_VERSION_ID}/sle repo-sle-update
zypper ar -n "Update repository of openSUSE Backports" http://download.opensuse.org/update/leap/${NEW_VERSION_ID}/backports/ repo-backports-update
zypper ref
zypper -n dup --allow-vendor-change
if [ $? -ne 0 ];then
echo "Migration went wrong. Please fix the issues and try again."
zypper -n dup
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried this script yesterday and I think we have conflicts which must be solved manual.
There is at least the "netty" problem, where we require an older version, but a patch require the newer version.

We also have a problem with the vendor of a product.

@juliogonzalez should we remove the -n and let the user make decissions?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried this script yesterday and I think we have conflicts which must be solved manual.

What do you mean? Can you provide details? AFAIK @mbussolotto tested the upgrade and worked for him.

There is at least the "netty" problem, where we require an older version, but a patch require the newer version.

Can you provide more details? What patch is requiring the newer versions? I remember you adjusted one spec to require our version, to fix a bug caused by a version bump at Leap 15.3

Wasn't that enough?

We also have a problem with the vendor of a product.

You mean the discussion I have with Adrian? That's true, but doesn't really break the issue if we allow vendor change.

@juliogonzalez should we remove the -n and let the user make decissions?

I don't see why? The script should just work, no questions asked.

And BTW: why are we removing --allow-vendor-change?

Copy link
Member Author

@mbussolotto mbussolotto May 30, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And BTW: why are we removing --allow-vendor-change?

I tested upgrade from JeOS image and it wasn't required, I will re-add it if you think it's safer

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But did the vendor change happened or not?

If it happened, then removing is OK.

Keep in mind there are a few packages we removed from our codestream and will now come from Leap, so those must change the vendor.

ret=${?}
if [[ ${ret} -ne 0 ]];then
echo "Migration went wrong. Please fix the issues and try again. return code is ${ret}"
exit -1
fi

mbussolotto marked this conversation as resolved.
Show resolved Hide resolved
CURRENT_VERSION_ID=$(cat /etc/os-release | grep VERSION_ID | cut -f2 -d=)

if [[ "${CURRENT_VERSION_ID}" != "\"${NEW_VERSION_ID}\"" ]]; then
echo "Migration went wrong. Expected version is ${NEW_VERSION_ID} instead is ${CURRENT_VERSION_ID}"
echo "Please try to re-run this script"
exit -1
fi

echo
echo "==================================================================="
echo "If you did not yet migrate the database to postgresql13, do so now"
echo "If you did not yet migrate the database to the new postgres version, do so now"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One minor thing about this: I don't think the user can do the DB migration before this script runs.

Even if the new postgres is installed pg-migrate-x-to-y.sh and the related scripts would come from the old Uyuni version, so they won't be adapte to Postgres 14.

Shouldn't this sentece tell the user to run the DB migration script without any "if"?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct, also if new postgres version is installed, pg-migrate-x-to-y.sh is still required

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should be better now

echo "by running /usr/lib/susemanager/bin/pg-migrate-x-to-y.sh"
echo
echo "Reboot system afterwards."
Expand Down
2 changes: 2 additions & 0 deletions susemanager/susemanager.changes
Original file line number Diff line number Diff line change
@@ -1,3 +1,5 @@
- Update server-migrator to dist-upgrade to openSUSE 15.4

-------------------------------------------------------------------
Tue Apr 19 12:11:26 CEST 2022 - jgonzalez@suse.com

Expand Down