Content Lifecycle Management

Content lifecycle management allows you to customize and test packages before updating production clients. This is especially useful if you need to apply updates during a limited maintenance window.

Content lifecycle management allows you to select software channels as sources, adjust them as required for your environment, and thoroughly test them before installing onto your production clients.

While you cannot directly modify vendor channels, you can clone them and then modify the clones by adding or removing packages and custom patches. You can assign these cloned channels to test clients to ensure they work as expected.

By default, cloned vendor channels match the original vendor channel and automatically select the dependencies. You can disable the automatic selection for cloned channels by adding the following option in /etc/rhn/rhn.conf:

java.cloned_channel_auto_selection = false

Then, when all tests pass, you can promote the cloned channels to production servers.

This is achieved through a series of environments that your software channels can move through on their lifecycle. Most environment lifecycles include at least test and production environments, but you can have as many environments as you require.

This section covers the basic content lifecycle procedures, and the filters available. For more specific examples, see Content Lifecycle Management Examples.

1. Create a Content Lifecycle Project

To set up a content lifecycle, you need to begin with a project. The project defines the software channel sources, the filters used to find packages, and the build environments.

Procedure: Creating a Content Lifecycle Project

  1. In the Uyuni Web UI, navigate to Content Lifecycle  Projects, and click Create Project.

  2. In the Label field, enter a label for your project. The Label field only accepts lowercase letters, numbers, periods, hyphens, and underscores.

  3. In the Name field, enter a descriptive name for your project.

  4. Click the Create button to create your project and return to the project page.

  5. Click Attach/Detach Sources.

  6. In the Sources dialog, select the source type, and select a base channel for your project. The available child channels for the selected base channel are displayed, including information on whether the channel is mandatory or recommended.

  7. Check the child channels you require, and click Save to return to the project page. The software channels you selected should now be showing.

  8. Click Attach/Detach Filters.

  9. In the Filters dialog, select the filters you want to attach to the project. To create a new filter, click Create new Filter.

  10. Click Add Environment.

  11. In the Environment Lifecycle dialog, give the first environment a name, a label, and a description, and click Save. The Label field only accepts lowercase letters, numbers, periods, hyphens, and underscores.

  12. Continue creating environments until you have all the environments for your lifecycle completed. You can select the order of the environments in the lifecycle by selecting an environment in the Insert before field when you create it.

2. Filter Types

Uyuni allows you to create various types of filters to control the content used for building the project. Filters allow you to select which packages are included or excluded from the build. For example, you could exclude all kernel packages, or include only specific releases of some packages.

The supported filters are:

  • package filtering

    • by name

    • by name, epoch, version, release, and architecture

    • by provided name

  • patch filtering

    • by advisory name

    • by advisory type

    • by synopsis

    • by keyword

    • by date

    • by affected package

  • module

    • by stream

Package dependencies are not resolved during content filtering.

There are multiple matchers you can use with the filter. Which ones are available depends on the filter type you choose.

The available matchers are:

  • contains

  • matches (must take the form of a regular expression)

  • equals

  • greater

  • greater or equal

  • lower or equal

  • lower

  • later or equal

2.1. Filter rule Parameter

Each filter has a rule parameter that can be set to either Allow or Deny. The filters are processed like this:

  • If a package or patch satisfies a Deny filter, it is excluded from the result.

  • If a package or patch satisfies an Allow filter, it is included in the result (even if it was excluded by a Deny filter).

This behavior is useful when you want to exclude large number of packages or patches using a general Deny filter and "cherry-pick" specific packages or patches with specific Allow filters.

Content filters are global in your organization and can be shared between projects.

If your project already contains built sources, when you add an environment it is automatically populated with the existing content. Content is drawn from the previous environment of the cycle if it had one. If there is no previous environment, it is left empty until the project sources are built again.

3. Filter Templates

To help with creating filters for some common scenarios, Uyuni offers filter templates. When applied, these templates help creating a set of filters in advance, tailored for a specific use case.

This section describes available templates and their usages.

3.1. Live Patching Based on a SUSE Product

In a project that contains live patching, regular future kernel packages must be excluded so that only live patch packages are offered as updates to clients. On the other hand, already installed regular kernel packages must still be included to keep system integrity.

When applied, this template creates three filters required to achieve this behavior:

  • Allow patches that contain kernel-default package equal to a base kernel version

  • Deny patches that contain reboot_suggested keyword

  • Deny patches that contain a package which provides the name installhint(reboot-needed)

For more information on how to set up a live patching project, see administration:content-lifecycle-examples.adoc#exclude-higher-kernel-version.

Procedure: Applying the Template

  1. In the Uyuni Web UI, navigate to Content Lifecycle  Filters, and click Create Filter.

  2. In the dialog, click Use a template. The inputs will change accordingly.

  3. In the Prefix field, type a name prefix. This value will be prepended to the name of every individual filter created by the template. If the template is being applied in the context of a project, this field will be prefilled with the project label.

  4. In the Template field, select Live patching based on a SUSE product.

  5. In the Product field, select the product you wish to set up live patching for.

  6. In the Kernel field, select a kernel version from the list of versions available in the selected product. The filter to deny the later regular kernel patches will be based on this version.

  7. Click Save to create the filters.

  8. Navigate to Content Lifecycle  Projects and select your project.

  9. Click Attach/Detach Filters.

  10. Select the three filters that have the specified prefix, and click Save.

3.2. Live Patching Based on a System

When you want to set up a live patching project based on a kernel version installed in a specific registered system, you can use the "live patching based on a system" template.

When applied, this template creates three filters required to achieve this behavior:

  • Allow patches that contain kernel-default package equal to a base kernel version

  • Deny patches that contain reboot_suggested keyword

  • Deny patches that contain a package which provides the name installhint(reboot-needed)

For more information on how to set up a live patching project, see administration:content-lifecycle-examples.adoc#exclude-higher-kernel-version.

Procedure: Applying the Template

  1. In the Uyuni Web UI, navigate to Content Lifecycle  Filters, and click Create Filter.

  2. In the dialog, click Use a template. The inputs will change accordingly.

  3. In the Prefix field, type a name prefix. This value will be prepended to the name of every filter created by the template. If the template is being applied in the context of a project, this field will be prefilled with the project label.

  4. In the Template field, select Live patching based on a specific system.

  5. In the System field, select a system from the list, or start typing a system name to narrow down the options.

  6. In the Kernel field, select a kernel version from the list of versions installed in the selected system. The filter to deny the later regular kernel patches will be based on this version.

  7. Click Save to create the filters.

  8. Navigate to Content Lifecycle  Projects and select your project.

  9. Click Attach/Detach Filters.

  10. Select the three filters that have the specified prefix, and click Save.

3.3. AppStream Modules with Defaults

When you want to have all the modules available in a modular repository included in your project, you can automatically add them using this filter template.

When applied, this template creates an AppStream filter per module and its default stream.

If this process is done from the project’s page, the filters are added to the project automatically. Otherwise, the created filters can be listed in Content Lifecycle  Filters and be added to any project as needed.

Each individual filter can be edited to select a different module stream, or removed altogether to exclude that module from the target repositories.

Because not all module streams are compatible with each other, changing individual streams may prevent successful resolution of modular dependencies. When this happens, the filters pane in the project details page will show an error describing the problem, and the build button will be disabled until all the module selections are compatible.

Since Red Hat Enterprise Linux 9, modules do not have any defined default streams. Therefore, using this template with Red Hat Enterprise Linux 9 sources will have no effect.

For more information on how to set up AppStream repositories with content lifecycle management, see administration:content-lifecycle-examples.adoc#appstream-filters.

Procedure: Applying the Template

  1. In the Uyuni Web UI, navigate to Content Lifecycle  Projects, and select your project.

  2. In the Filters section, click Attach/Detach Filters, and then click Create New Filter.

  3. In the dialog, click Use a template. The inputs will change accordingly.

  4. In the Prefix field, type a name prefix. This value will be prepended to the name of every filter created by the template. If the template is being applied in the context of a project, this field will be prefilled with the project label.

  5. In the Template field, select AppStream modules with defaults.

  6. In the Channel field, select a modular channel to get the modules from. In this dropdown, only the modular channels are displayed.

  7. Click Save to create the filters.

  8. Scroll to the Filters section to see the newly attached AppStream filters.

  9. You can edit/remove any individual filter to tailor the project to your needs.

4. Build a Content Lifecycle Project

When you have created your project, defined environments, and attached sources and filters, you can build the project for the first time.

Building applies filters to the attached sources and clones them to the first environment in the project.

You can use the same vendor channels as sources for multiple content projects. In this case, Uyuni does not create new patch clones for each cloned channel. Instead, a single patch clone is shared between all of your cloned channels. This can cause problems if a vendor modifies a patch; for example, if the patch is retracted, or the packages within the patch are changed. When you build one of the content projects, all the channels that share the cloned patch are synchronized with the original by default, even if the channels are in other environments of your content project, or other content project channels in your organization. You can change this behavior by turning off automatic patch synchronization in your organization settings. To manually synchronize the patch later for all channels sharing the patch, navigate to Software  Manage  Channels, click the channel you want to synchronize and navigate to the Sync subtab. Even manual patch synchronization affects all organization channels sharing the patch.

Procedure: Building a Content Lifecycle Project

  1. In the Uyuni Web UI, navigate to Content Lifecycle  Projects, and select the project you want to build.

    Make sure you have the environment available before building the project.

  2. Review the attached sources and filters, and click Build.

  3. Provide a version message to describe the changes or updates in this build.

  4. You can monitor build progress in the Environment Lifecycle section.

After the build is finished, the environment version is increased by one and the built sources, such as software channels, can be assigned to your clients.

5. Promote Environments

When the project has been built, the built sources can be sequentially promoted to the environments.

Procedure: Promoting Environments

  1. In the Uyuni Web UI, navigate to Content Lifecycle  Projects, and select the project you want to work with.

  2. In the Environment Lifecycle section, locate the environment to promote to its successor, and click Promote.

  3. You can monitor build progress in the Environment Lifecycle section.

6. Assign Clients to Environments

When you build and promote content lifecycle projects, Uyuni creates a tree of software channels. To add clients to the environment, assign the base and child software channels to your client using Software  Software Channels in the System Details page for the client.

Newly added cloned channels are not assigned to clients automatically. If you add or promote sources you need to manually check and update your channel assignments.

Automatic assignment is intended to be added to Uyuni in a future version.