Product Management/Code11/Upgrade

From openSUSE

Upgrade of Products Based on Code11

Version: Code 11

openSUSE 11.1 and SLE11

Assumptions

• for the following assume upgrade to SP2, so there might be SP1 or GA as starting points.
• the SP medium contains a complete product repository, useful for bare metal installation

Requirements

The process must be package based - Migration with 3rd party tools, which only can handle .rpm packages, must work. Using 3rd party tools might need additional package installs/removals and repository management.

Proposal

Basics

• Migration is handled as 'distribution upgrade'

This honors package renames, splits, drops and additions. It also will do architecture updates of packages when available.

How the new repository is obtained

The basic product availability is handled in the installed product description. Each product includes a section like this:

<?xml version="1.0" encoding="UTF-8"?>
<product schemeversion="0.0">
    <vendor>Novell</vendor>
    <name>openSUSE</name>
    <version>11.0</version>
    ...
    <upgrades>
       <upgrade>
         <name>openSUSE_11.1</name>
         <summary>openSUSE 11.1</summary>
         <repository>http://download.opensuse.org/distribution/openSUSE/11.1</repository>
         <notify>true</notify>
         <status>stable</status>
       </upgrade>
       <upgrade>
         <name>openSUSE_Factory</name>
         <summary>openSUSE Factory</summary>
         <repository>http://download.opensuse.org/distribution/openSUSE/Factory</repository>
         <notify>false</notify>
         <status>unstable</status>
       </upgrade>
    <upgrades>
    ...
</product>

This section may not have entries (or be incomplete) during the original release of the product. The package is then updated, completing the product definition as an update of the release/product package (which contains the definition of the product).

openSUSE

For openSUSE, it is enough to know the repository that needs to be added before performing the distribution upgrade. The previous example covers this.

Enterprise products

For SLE and some addons, the binary repository is not available. Therefore, a re-registration should happen in order to get a migration repository.

In this case, the update repository will offer a migration package for a certain migration path, containing a special product that can trigger the addition of a repository after doing a re-registration.

The upgrade list in the product will need to include the name of the product package instead of the repository:

<?xml version="1.0" encoding="UTF-8"?>
<product schemeversion="0.0">
    <vendor>Novell</vendor>
    <name>SLES</name>
    <version>11.0</version>
    ...
    <upgrades>
       <upgrade>
         <name>SLES_11_SP1</name>
         <summary>SLES 11 SP1</summary>
         <product>SLES_11_SP1</product>
         <notify>true</notify>
         <status>stable</status>
       </upgrade>
    <upgrades>
    ...
</product>

The product tag is used to find a migration package providing this product. The installation of this migration package results in a product installed that can be used on re-registration to get the repository.

Notification

While any tool can read the available migration paths from the product definition, ZYpp will include a Product API that will read this information as a convenience.

PackageKit ZYPP backend will implement PackageKit's GetDistroUpgrades method using this API.

Applet will notify the user by using the PackageKit's GetDistroUpgrades service.

Workflow

It is enough to know the repository that needs to be added before performing the distribution upgrade. The previous example covers this.

The workflow would be like:

• Triggering the migration tool (explained later)
• Optionally update the release package to make sure the upgrade list is updated
• Read the product definition to get the available migration paths
• The user chooses one path
• The tool either adds the required repository, or installs the required migration package.
• In the second case, re-registration is performed
• distribution upgrade is done.
• Migration repository is removed, or when necessary, the migration package
• reboot
• re-registration is done to get the relevant repositories.

This workflow is performed by a special tool included in the system, called yast2-wagon.

Migration tool

Convenience tool to guide the user through the migration, it does not contain any extra functionality beyond what's available through command line tools.

• tool for doing all tricky parts under nice GUI
• packaged on its own
• might provide option 'go to FCS, go to FCS+Updates'
• must provide rollback functionality to cancel migration (downgrade the package containing the migration product)
• tool should check if it needs to update itself
• available from updaters

Scenarios

This translates to different scenarios:

1. boot from media, the YaST installer uses the same dist-upgrade algorithm
2. scripted
   1. zypper lu contains the patch
   2. zypper up
   3. suse_register (not needed, repos might be adapted manually for disconnected setups etc)
   4. zypper dup
   5. suse_register (not needed, repos might be adapted manually for disconnected setups etc)
3. YOU
   1. YOU shows the initiating patch
   2. install the initiating patch via YOU and run migration tool
   3. migration tool: register migration status
   4. migration tool: run dist-upgrade algorithm
   5. migration tool: register final status
4. updater applets
   1. applet shows the initiating patch
   2. install the initiating patch via applet and run migration tool
   3. migration tool: register migration status
   4. migration tool: run dist-upgrade algorithm
   5. migration tool: register final status
5. rpm-only
   1. got mail about SP being available
   2. not needed
   3. add SP medium to repositories list
   4. update the packages using 3rd party tool
   5. not needed

Migration product package

• migration product package changes:
  • GA: empty
  • SP released: contains migration product description (/etc/zypp/products.d)
  • SP2 installed:
• migration package definition - the product flavor will be 'migration'
• the migration package is present on installation medium

Repositories

• We will need migration products, but we can go without -Online repo because it is the same as -Pool
• NCC/SMT changes are not needed
• For delta-rpms, the repository needs to be rpm-md.
  • on NCC/SMT - rpm-md
  • on medium - susetags

Migration via media:

• you need access to updated repositories (e.g. via network)

Add-ons

• dependencies need to work on the package level
• as the list of 3rd party addons is not known, we need supplements work on the package level, patch view of the update tools need to handle this gracefully
• wagon to provide UI for adapting the add-ons before the upgrade