Product Management/Code11

From openSUSE

Code11 product handling

Proposal 0.2

Related features:

• #300654: De-install of add-on product
• #300899: install the security updates for own packages
• #301949: Support for update-kits
• #302194: Full support for 'driver kits'
• #302920: Update method for Service-Packs/PatchCDs with standard Disk-Layout
• #303812: PatchCD replacement necessary
• #304502: Hide update from conflicting add-on product

Requirements

media agnostic

• products come on CD, DVD, http, ftp, ...;Data structures should not be depending on the media

tool agnostic

• products can be installed with YaST, zypper, smart, yum, ...
• No control/config is generated by YaST which is required for maintainability or later updates/migrations.
  • (/etc/YaST2/ProductFeatures is generated by YaST in openSUSE 11.0, one cannot register without it)

zypp based tools provide additional functionality/usability

• checking if a product is correctly installed
• upgrading per product
• run workflow to configure product

A product is considered 'installed' when the user said so

• by selecting a package
• dependencies of this package express the needs of the product
• Buildservice wants a single description for products, the 'product' package must be generated from this description.

Registration

• Registration is done after product installation and serves the following purposes
  • keep track of customer/product relations
  • statistical information
  • provide list of additional repositories
    • for updates
    • for drivers (e.g. ati/nvidia)
    • for extra packages (e.g. debuginfo packages)
• The client will provide the following data
  • installed products (a target, e.g. product-version-architecture)
    • The 'target' is encoded in the product description below /etc/products.d
    • client architecture (i.e. product is i386, client is i686)
      • this is a computed value (aka libzypp architecture)
  • locale (preferred language)
  • timezone (optional, or any other geo information to redirect to proxies)
  • flavor (e.g. dvd, ftp, live, ...; mostly for statistics)
    • Probably also useful for NCC. E.g. "eval" could be a flavor and NCC does not return an update channel for this
    • what else ?
• Registration is not mandatory.
  • The registration workflow offered by YaST is a convenience to get the 'right' repositories
  • Its possible to use 3rd party tool to keep a system up-to-date
  • This requires knowledge of the URLs of update repos (and evtl. access credentials)

Motivation

• 'content' file is wrong as it mixes repository (media) metadata with product metadata
• https://bugzilla.novell.com/show_bug.cgi?id=205392 (product vs. distproduct)

Recommendations

There are two different 'product metadata' files.

1. Metadata provided by the repository offering the product. This is the data available _prior_ to product installation.
2. Metadata provided by the product itself. This is the data available _after_ product installation.

Drop susetags, make rpmmd primary format

• Media should ideally provide also .solv format
• For Code11, 'susetags' will be deprecated but still supported

Update(maintenance) vs. Upgrade (sp migration)

• Always run 'dist upgrade' algorithm (in order to support splits, renames, drop and new packages) ?
  • Core packages will be explicit dependencies of the *-release package
• Package architecture changes are hard to do in 'live' upgrades
  • To rpm, i.e glibc.i586 and glibc.i686 are two different packages
    • a normal update will result in file conflicts
    • one has to remove one before installing the other
    • this will leave the system without glibc
• Either
  • disallow arch changes during live migrations
    • solver can take care
    • doing 'instsys' migrations (booting into ramdisk, run upgrade in YaST) will still allow arch changes
    • this would make 'live' and 'instsys' migrations behave differently
  • or don't provide arch updates at all

• For package split, similar constraints apply
  • with splits, it can also happen that for a short time a core piece is not available and the whole running stack crashes.
  • core package splits have to be handled at checkin time.
  • For the usual use cases package splits will work fine, and the special ones are not detectable by a tool.

A 'product' is delivered via a repository (url or media)

• The repository provides a .repo file containing a high-level product description, including
  • tags (i.e. 'sle11' to denote the codebase)
  • flags (used by YaST)
• .repo file contains all information the user needs to make a decision to install the product
• A single repository can provide multiple products.
• For 'susetags' repositories, see the content file

A 'product' has a distinguished package

• The dependencies of this package determine the 'installability' of the product.
• The dependencies of this package controls updates through provides and obsoletes.
• Q: How to easily detect 'product' packages in a repository ?
  • Explicit 'Provides: product()'
  • Explicit 'Provides: product(<name>) = <version>-<release>'

A repository might provide an 'installation.xml' file

• used to control additional functionalities when using YaST to install the product, like running a configuration workflow. (See FATE #301997)

An installed product is a description file below /etc/products.d

• This file contains data for
  • registration
  • list of packages
    • used for product removal
    • used for product verification ('SPident')
    • used for product supportability
  • as <name>[ <version> [<release> [<arch>]]]
    • (version, release and arch are optional. Just name means 'any version', just name+version means 'any release')
    • YaST creates a symlink /etc/products.d/baseproduct to the 'first' product to denote the 'base' distribution
      • only YaST needs the 'base' product, this symlink is not present when using other install tools besides YaST
      • when switching from 3rd party tool to YaST, this symlink is not present. YaST can
        • warn the admin and ask the admin to provide the symlink
        • create the symlink (easy, if there's only a single product)
        • ask the admin to choose the 'base' product (needs popup)
• This file has yaml, json or 'ini' format. _Not_ xml.
  • (recommendation: .ini as we're already using this format)
• See here for the current implementation

Metadata requirements

• A product needs the following properties

 (M = mandatory, O = optional;  B = before install, A = after install; B implies A)

Note: update url is specifying an update repository, registration url is specifying a registration server

• If only update url is set, no registration is needed.
• If only registration url is set, registration is needed.
• If neither are set, the product won't get any updates.
• If both are set, the update url defines the 'default' update repo. If the user registers, he might get 'extra updates' as added value in exchange for his registration.

(On the long run update and registration URL should be identical (See Fate #301743) and the repository server decides if a registration is needed.)

Metadata representation

For 'susetags' repositories, the 'content' file is the representation of the product metadata. See here for its syntax.

Side-effects

Satsolver must not downgrade package versions due to dependencies

• - only explicit downgrades are allowed

Do not use 'susetags' for media, but rpmmd (or .solv) instead

• For Code11, the 'susetags' format will be deprecated but still fully supported

Provide .repo file on media

• refresh y/n
  • if no: fixed media, this repo is never updated

'product()' must be an explicit provide

• of the package in order to detect such package properly and trigger registration
• See here for a complete description

Open Issues

• Locking of 'product' packages by default ?
  • How to detect a 'product' package ?
    • Check for /etc/products.d/x.y provides ?

• Update (sp migration) with multiple installed products
  • Must be dealt with on the package level

• Kiwi images can contain multiple products
  • Studio / Kiwi have to check for a single 'product' package

• What kind of credentials for NCC ?
  • Migration of /etc/zmd/{deviceid,secret} to new location on SLE10->SLE11 upgrade

Installed products

See here for a discussion on installed products.