diff --git a/adoc/admin-migrate-caasp4.5.adoc b/adoc/admin-migrate-caasp4.5.adoc new file mode 100644 index 000000000..af9d40d09 --- /dev/null +++ b/adoc/admin-migrate-caasp4.5.adoc @@ -0,0 +1,111 @@ +[#caasp-migrate-4.5] +== Migration to {productname} 4.5 + +. The server should be connected to servers like SCC or RMT. Other migration scenarios are covered in the SLES upgrade guide. ++ +[NOTE] +==== +In order to reconnect your system to the registration server, run: +`SUSEConnect -r SUSEConnect -p sle-module-containers/15.1/x86_64 -r ` +==== +. You also need the new `zypper migration` plugin. This plugin is used to perform the needed tasks in order to migrate the node itself to the latest version of {platform}, such as updating the repositories to the new ones, and calling `zypper dup`. This plugin is provided by the `zypper-migration-plugin` package. Therefore, install the `zypper-migration-plugin` package: ++ +---- +zypper -n in zyppper-migration-plugin +---- +. Then, run the newly installed `zypper-migration` plugin (on the management node first, then on the rest of the nodes): ++ +---- +zypper migration +---- ++ +[NOTE] +==== +If you want migration to progress non-interactive, you can add the flags: `--non-interactive --auto-agree-with-licenses` +==== +. Check that all required repositories are enabled again and have the correct version. Run: ++ +---- +zypper lr -uE +---- ++ +Verify that all repositories on the following list are present and enabled: ++ +[NOTE] +==== +The actual Aliases might be different from the ones shown here if they were configured differently during the initial installation of {sle}. + +The URIs will have long UUID strings (`update?`,`product?`) attached to them. The UUIDs identify your personal licensed product or update repositories. +These have been omitted from this output exapmle. +==== ++ +[options="header",cols="2"] +|=== +|Alias |URI +|Basesystem_Module_15_SP2_x86_64:SLE-Module-Basesystem15-SP2-Pool | https://updates.suse.com/SUSE/Products/SLE-Module-Basesystem/15-SP2/x86_64/ +|Basesystem_Module_15_SP2_x86_64:SLE-Module-Basesystem15-SP2-Updates | https://updates.suse.com/SUSE/Updates/SLE-Module-Basesystem/15-SP2/x86_64/ +|Containers_Module_15_SP2_x86_64:SLE-Module-Containers15-SP2-Pool | https://updates.suse.com/SUSE/Products/SLE-Module-Containers/15-SP2/x86_64/ +|Containers_Module_15_SP2_x86_64:SLE-Module-Containers15-SP2-Updates | https://updates.suse.com/SUSE/Updates/SLE-Module-Containers/15-SP2/x86_64/ +|Python_2_Module_15_SP2_x86_64:SLE-Module-Python2-15-SP2-Pool | https://updates.suse.com/SUSE/Products/SLE-Module-Python2/15-SP2/x86_64/ +|Python_2_Module_15_SP2_x86_64:SLE-Module-Python2-15-SP2-Updates | https://updates.suse.com/SUSE/Updates/SLE-Module-Python2/15-SP2/x86_64/ +|SUSE_CaaS_Platform_4.5_x86_64:SUSE-CAASP-4.5-Pool | https://updates.suse.com/SUSE/Products/SUSE-CAASP/4.5/x86_64/ +|SUSE_CaaS_Platform_4.5_x86_64:SUSE-CAASP-4.5-Updates | https://updates.suse.com/SUSE/Updates/SUSE-CAASP/4.5/x86_64/ +|SUSE_Linux_Enterprise_Server_15_SP2_x86_64:SLE-Product-SLES15-SP2-Pool | https://updates.suse.com/SUSE/Products/SLE-Product-SLES/15-SP2/x86_64/ +|SUSE_Linux_Enterprise_Server_15_SP2_x86_64:SLE-Product-SLES15-SP2-Updates | https://updates.suse.com/SUSE/Updates/SLE-Product-SLES/15-SP2/x86_64/ +|Server_Applications_Module_15_SP2_x86_64:SLE-Module-Server-Applications15-SP2-Pool | https://updates.suse.com/SUSE/Products/SLE-Module-Server-Applications/15-SP2/x86_64/ +|Server_Applications_Module_15_SP2_x86_64:SLE-Module-Server-Applications15-SP2-Updates | https://updates.suse.com/SUSE/Updates/SLE-Module-Server-Applications/15-SP2/x86_64/ +|=== +. Check if `skuba` was indeed upgraded for 4.5: ++ +---- +skuba version +---- ++ +[IMPORTANT] +==== +The version must be >= `skuba-2.1`. +`skuba 2` corresponds to {productname} 4.5, while `skuba 1.0-1.4` corresponds to {productname} 4. +==== +. And now run the skuba cluster upgrade commands as it's done below. ++ +- First, check if there are any addons or components to upgrade before you upgrade the nodes: ++ +---- +skuba cluster upgrade plan +skuba addon upgrade plan +skuba addon upgrade apply +---- +- Then, check with `cluster status` if all nodes have the same kubernetes version (which must be 1.17.x): ++ +---- +skuba cluster status +---- ++ +[NOTE] +==== +If not all nodes are properly upgraded to the same Kubernetes version, then the ones with an older Kubernetes version must be upgraded before migrating according to the previous documentation. +==== ++ +- Finally, if all nodes have the same kubernetes version, you first upgrade the cri-o config: ++ +---- +skuba cluster upgrade localconfig +---- +- Run `skuba node upgrade`: ++ +---- +skuba node upgrade apply —-user sles —-sudo —-target +---- +- Done! Before repeating the same cycle with the rest of the nodes, **please make sure** that all the components of the kubernetes stack **are running** on the freshly upgraded node. You can do this with the following command: ++ +---- +kubectl get all -n kube-system +---- +. After upgrading all the nodes, make sure you run another addon upgrade across the cluster: ++ +---- +skuba addon upgrade plan +skuba addon upgrade apply +---- + +After following all these instructions you should be running {productname} 4.5. Take a look at the release notes of this release to further inspect the new features that this release brings. Enjoy!