-
Notifications
You must be signed in to change notification settings - Fork 174
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
Server migrator to 15.4 #4704
Conversation
c706850
to
7250721
Compare
62a37cd
to
2261b47
Compare
@@ -118,7 +118,7 @@ Requires: postgresql13-contrib | |||
Conflicts: postgresql-implementation >= 14 | |||
Conflicts: postgresql-contrib-implementation >= 14 | |||
%endif # if sle_version >= 150400 | |||
%else # not suse_version | |||
%else # not suse_version or opensuse |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 :) )
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we will have postgresql14
update postgres version for no suse product
Quick update. Last changes allow to install pg14, but we still have an issue
I'm investigating on it (it might be something related to `pg_hba.conf so similar to this #5184 ...or simply something on my environment :) ) |
Just in case... check if the system time for your server is OK. Specially if you are using KVM snapshots. |
ok found it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some minor comments.
Co-authored-by: Julio González Gil <juliogonzalez@users.noreply.github.com>
Co-authored-by: Julio González Gil <juliogonzalez@users.noreply.github.com>
Co-authored-by: Julio González Gil <juliogonzalez@users.noreply.github.com>
Co-authored-by: Julio González Gil <juliogonzalez@users.noreply.github.com>
@@ -118,7 +118,7 @@ Requires: postgresql13-contrib | |||
Conflicts: postgresql-implementation >= 14 | |||
Conflicts: postgresql-contrib-implementation >= 14 | |||
%endif # if sle_version >= 150400 | |||
%else # not suse_version | |||
%else # not suse_version or opensuse |
There was a problem hiding this comment.
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.
@@ -118,7 +118,7 @@ Requires: postgresql13-contrib | |||
Conflicts: postgresql-implementation >= 14 | |||
Conflicts: postgresql-contrib-implementation >= 14 | |||
%endif # if sle_version >= 150400 | |||
%else # not suse_version | |||
%else # not suse_version or opensuse |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we will have postgresql14
spacewalk/package/spacewalk.spec
Outdated
@@ -118,7 +118,7 @@ Requires: postgresql13-contrib | |||
Conflicts: postgresql-implementation >= 14 | |||
Conflicts: postgresql-contrib-implementation >= 14 | |||
%endif # if sle_version >= 150400 | |||
%else # not suse_version | |||
%else # not suse_version or opensuse | |||
Requires: postgresql >= 12 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you please put this and the line below to >= 14?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I approve this, we can can only really test it, if it is merged.
susemanager/bin/server-migrator.sh
Outdated
zypper -n dup --allow-vendor-change | ||
if [ $? -ne 0 ];then | ||
echo "Migration went wrong. Please fix the issues and try again." | ||
zypper -n dup |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
susemanager/bin/server-migrator.sh
Outdated
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" |
There was a problem hiding this comment.
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"?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should be better now
What does this PR change?
Upgrade server migrator to upgrade to 15.4.
GUI diff
No difference.
Documentation
Documentation required, issue will be created
DONE
Test coverage
No tests
DONE
Links
Fixes https://github.com/SUSE/spacewalk/issues/17546
Changelogs
Make sure the changelogs entries you are adding are compliant with https://github.com/uyuni-project/uyuni/wiki/Contributing#changelogs and https://github.com/uyuni-project/uyuni/wiki/Contributing#uyuni-projectuyuni-repository
If you don't need a changelog check, please mark this checkbox:
If you uncheck the checkbox after the PR is created, you will need to re-run
changelog_test
(see below)Re-run a test
If you need to re-run a test, please mark the related checkbox, it will be unchecked automatically once it has re-run: