Skip to content

Uyuni proxy upgrade keichwa #388

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.

Sign up for GitHub

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

Merged
merged 9 commits into from
Jul 24, 2020
Merged

Uyuni proxy upgrade keichwa #388

Show file tree
Hide file tree
Changes from 3 commits
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
9911d6b
start with proxy
keichwa Jul 21, 2020
a41c132
proxy upgrade procedure
keichwa Jul 21, 2020
5242c65
eadd uyuni proxy entry
keichwa Jul 21, 2020
20769cf
Update modules/upgrade/pages/proxy-uyuni.adoc
keichwa Jul 21, 2020
038615d
upgrade uyuni server: webui and autoyast
keichwa Jul 22, 2020
653fbad
rework according to feedback
keichwa Jul 24, 2020
7a4bec1
disable proxy-autoyast-uyuni.adoc which is currently untested
keichwa Jul 24, 2020
0448b58
Update modules/upgrade/pages/proxy-autoyast-uyuni.adoc
keichwa Jul 24, 2020
f26fe26
Update modules/upgrade/pages/proxy-uyuni.adoc
keichwa Jul 24, 2020
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
1 change: 1 addition & 0 deletions .changelog
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,7 @@

# Last packaged: 2020-07-02

- New section Upgrade Uyuni Proxy in Upgrade Guide
- New section Upgrade Uyuni Server in Upgrade Guide
- Add GPG information about Oracle clients to SUMA (bsc#1173520)
- Add hostname admonition to public cloud sections (bsc#1173621)
Expand Down
5 changes: 5 additions & 0 deletions modules/upgrade/nav-upgrade-guide.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,8 +22,13 @@ ifeval::[{uyuni-content} == true]
*** xref:server-major-upgrade-uyuni.adoc[Server - Major Upgrade]
endif::[]
** xref:proxy-intro.adoc[Upgrade the Proxy]
ifeval::[{uyuni-content} == true]
*** xref:proxy-uyuni.adoc[Proxy - Upgrade Procedure]
endif::[]
ifeval::[{suma-content} == true]
*** xref:proxy-x.adoc[Proxy - X Upgrade]
*** xref:proxy-y-z.adoc[Proxy - Y or Z Upgrade]
endif::[]
** xref:client-intro.adoc[Upgrade the Clients]
*** xref:client-x.adoc[Client - X Upgrade]
** xref:db-intro.adoc[Upgrade the Database]
Expand Down
5 changes: 4 additions & 1 deletion modules/upgrade/pages/proxy-intro.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,14 +2,16 @@
= Upgrade the Proxy

{productname} Proxies are managed in the same way as clients.
ifeval::[{suma-content} == true]
Maintenance updates (MU) can be installed on a {productname} Proxy in the same way as other clients.
MU updates require a restart of the proxy service.
endif::[]

Before you perform any proxy update, schedule a maintenance window.
The clients registered to {productname} through the proxy will not be able to connect to {productname} while the update is in progress.
For more information about maintenance windows, see xref:administration:maintenance-window.adoc[].


ifeval::[{suma-content} == true]
{productname} uses an [literal]``X.Y.Z`` versioning schema.
To determine which upgrade procedure you need, look at which part of the version number is changing.

Expand All @@ -30,3 +32,4 @@ Upgrading within the same minor version.
This is often referred to as a maintenance update.
For example, upgrading from 4.0.0 to 4.0.2.
See xref:upgrade:proxy-y-z.adoc[].
endif::[]
51 changes: 51 additions & 0 deletions modules/upgrade/pages/proxy-uyuni.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,51 @@
[[proxy-uyuni-upgrade]]
= Proxy - Upgrade Procedure

Before you perform any proxy update, schedule a maintenance window.
The clients registered to {productname} through the proxy will not be able to connect to {productname} while the update is in progress.
For more information about maintenance windows, see xref:administration:maintenance-window.adoc[].



== Upgrade the Proxy

To upgrade a proxy you first stop the proxy service, then you replace the software repositories and update the software, and finally you restart the proxy service.



.Procedure: Updating the {productname} Proxy
. On the {productname} Proxy, stop the proxy service:
+
----
spacewalk-proxy stop
----

// there is no chance to fix any issues during migration,
// make sure you have a backup before continuing. If you are
// running Uyuni server on a virtual machine, it is advisable
// to create a snapshot before performing the migration!

. Replace and refresh software repositories:
+
----
mv /etc/zypp/repos.d /etc/zypp/repos.d.old
Copy link
Member

Choose a reason for hiding this comment

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

Huh? what's this :-?

Copy link
Contributor

Choose a reason for hiding this comment

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

It's creating a backup of the old repos directory but this is wrong. What if the user has some other repositories enabled?

Copy link
Member

Choose a reason for hiding this comment

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

On a proxy, it should not. This is not what worries me most. The whole script is what worries me. I think it's the wrong way to do the uprade.

Copy link
Member

@juliogonzalez juliogonzalez Jul 21, 2020 •
edited
Loading

Choose a reason for hiding this comment

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

Funny enough it seems we tell people to install the Uyuni Proxy not as a client: https://www.uyuni-project.org/uyuni-docs/uyuni/installation/install-proxy-uyuni.html

I don't know why this is this way. To me it seems strange and wrong, but OK. For now it is how it is. So the script seems to make sense.

Copy link
Member

@juliogonzalez juliogonzalez Jul 21, 2020 •
edited
Loading

Choose a reason for hiding this comment

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

Ah now I understand it. You tell them to it that way, but then you say this: https://www.uyuni-project.org/uyuni-docs/uyuni/installation/uyuni-proxy-registration.html (BTW the channel name for spacewalk-common-channels is not uyuni-proxy-stable-leap-151 bot uyuni-proxy-stable-leap)

So in the end this migration script is still wrong, as the proxies will be clients. If you run this script, yeah, the migration will work, but then the Server will still think the proxy is a Leap 15.1, so I guess it will crate a mess.

This what I suspect that needs to be done if you want to migrate:

  1. Add the Leap 15.2 channels with spacewalk-common-channels opensuse_leap15_2 opensuse_leap15_2-non-oss opensuse_leap15_2-non-oss-updates opensuse_leap15_2-updates opensuse_leap15_2-uyuni-client uyuni-proxy-stable-leap-152
  2. Sync them: spacewalk-repo-sync -p opensuse_leap15_2-x86_64 (this will sync the parent and all children).
  3. Adjust the proxies using SSM or one by one to use the Leap 15.2 channels you just added and synced. Remember to apply the changes.
  4. Perform the migration (this is the "gray" area for me, maybe this where they need to run spacewalk-proxy stop; zypper ref; zypper -n dup --allow-vendor-change; shutdown -r now directly on the proxies).

And that should be all.

As for the procedure to add the proxy, itself, I'd say its wrong. What should be required is: Clean openSUSE Leap 15.2 installed and 100% updated (now that we are switching), and then Proxy Registration and finally Uyuni Proxy Setup (BTW the requirements still say Leap 15.1)

BTW I just noticed we don't have uyuni-proxy-stable-leap-152, so time to create it.

Copy link
Member

@juliogonzalez juliogonzalez Jul 21, 2020 •
edited
Loading

Choose a reason for hiding this comment

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

OK, I thought a little about all this mess. Let's do the following:

  1. I will tag Uyuni tomorrow, and will no accept more submissions to the master branch (meanwhile I will prepare a MU as well)
  2. @keichwa and @mantel can test the migration of the proxy tomorrow and Thursday and have the doc ready by end of Thursday
  3. @jcayouette prepares the package and the PR for the website on Thursday by the end of the day, or Friday, early in the morning.
  4. I start the release on Friday morning, as soon as the PR and the package for the doc are ready.
  5. We create an issue for the Uyuni Proxy Installation, so we can remove that instruction about adding the repositories manually, but to be fixed on a future Uyuni release.

Sounds fair enough? That gives some more time to test the migration without that much pressure.

Please ACK tomorrow morning if we have an agreement.

Copy link

Choose a reason for hiding this comment

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

I answered too quickly yesterday. While this script probably would (sort of) work, the clean way to upgrade the proxy would be to initiate an autoyast upgrade from the server. This way all the information regarding the proxy would stay consistent. We even had this documented some time ago; biggest issue is providing a working autoyast file which is a bit tricky.

Copy link

Choose a reason for hiding this comment

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

So in the end this migration script is still wrong, as the proxies will be clients. If you run this script, yeah, the migration will work, but then the Server will still think the proxy is a Leap 15.1, so I guess it will crate a mess.

Maybe this could even be fixed up by refreshing the information from the proxy, but yes, the only really clean way is to perform the upgrade via autoyast so the server is aware of any modifications done to the proxy.

Copy link
Member

Choose a reason for hiding this comment

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

I think that providing manual instructions should be fine as well (if it is easier) as long as they are accurate. Something like what I described above.

Copy link

Choose a reason for hiding this comment

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

I think that providing manual instructions should be fine as well (if it is easier) as long as they are accurate. Something like what I described above.

Yes, especially as it is much easier than to fiddle around with autoyast files. We just need to confirm that the changes in the proxy's system can be updated to the new state afterwards.

mkdir /etc/zypp/repos.d
zypper ar -n "Main Repository" http://download.opensuse.org/distribution/leap/15.2/repo/oss repo-oss
zypper ar -n "Main Update Repository" http://download.opensuse.org/update/leap/15.2/oss repo-update
zypper ar -n "Non-OSS Repository" http://download.opensuse.org/distribution/leap/15.2/repo/non-oss repo-non-oss
zypper ar -n "Update Repository (Non-Oss)" http://download.opensuse.org/update/leap/15.2/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 ref
----

. Update software packages:
+
----
zypper -n dup --allow-vendor-change
----

. Reboot the {productname} Proxy:
+
----
shutdown -r now
----