Managing Content Views

orcharhino uses Content Views to create customized repositories from the repositories. To do this, you must define which repositories to use and then apply certain filters to the content. These filters include both package filters, package group filters, errata filters, and module stream filters. You can use Content Views to define which software versions a particular environment uses. For example, a Production environment might use a Content View containing older package versions, while a Development environment might use a Content View containing newer package versions.

Alternatively, a Default Organization View is an application-controlled Content View for all content that is synchronized to orcharhino. This type is useful if you want to register a host to orcharhino and access content using a subscription, without manipulating content views and lifecycle environments.

Each Content View creates a set of repositories across each environment, which orcharhino Server stores and manages. When you promote a Content View from one environment to the next environment in the application life cycle, the respective repository on orcharhino Server updates and publishes the packages.

Development Testing Production

Content View Version and Contents

Version 2 - example_software-1.1-0.noarch.rpm

Version 1 - example_software-1.0-0.noarch.rpm

Version 1 - example_software-1.0-0.noarch.rpm

The repositories for Testing and Production contain the example_software-1.0-0.noarch.rpm package. If you promote Version 2 of the Content View from Development to Testing, the repository for Testing regenerates and then contains the example_software-1.1-0.noarch.rpm package:

Development Testing Production

Content View Version and Contents

Version 2 - example_software-1.1-0.noarch.rpm

Version 2 - example_software-1.1-0.noarch.rpm

Version 1 - example_software-1.0-0.noarch.rpm

This ensures systems are designated to a specific environment but receive updates when that environment uses a new version of the Content View.

The general workflow for creating Content Views for filtering and creating snapshots is as follows:

  1. Create a Content View.

  2. Add one or more repositories that you want to the Content View.

  3. Optionally, create one or more filters to refine the content of the Content View.

  4. Optionally, resolve any package dependencies for a Content View.

  5. Publish the Content View.

  6. Optionally, promote the Content View to another environment.

  7. Attach the content host to the Content View.

If a repository is not associated with the Content View, the file /etc/yum.repos.d/redhat.repo remains empty and systems registered to it cannot receive updates.

Hosts can only be associated with a single Content View. To associate a host with multiple Content Views, create a composite Content View. For more information, see Creating a Composite Content View.

Package Dependency Resolution

Package dependency is a complication of package management. For more information about how to manage package dependencies within Content Views, see Resolving Package Dependencies.

Creating a Content View

Use this procedure to create a simple Content View. To use the CLI instead of the orcharhino management UI, see the CLI procedure.

Prerequisites

While you can stipulate whether you want to resolve any package dependencies on a Content View by Content View basis, you might want to change the default orcharhino settings to enable or disable package resolution for all Content Views. For more information, see Resolving Package Dependencies.

Procedure

  1. In the orcharhino management UI, navigate to Content > Content Views and click Create New View.

  2. In the Name field, enter a name for the view. orcharhino automatically completes the Label field from the name you enter.

  3. In the Description field, enter a description of the view.

  4. Optional: if you want to solve dependencies automatically every time you publish this Content View, select the Solve Dependencies check box. Dependency solving slows the publishing time and might ignore any Content View filters you use. This can also cause errors when resolving dependencies for errata.

  5. Click Save to create the Content View.

  6. In the Repository Selection area, select the repositories that you want to add to your Content View, then click Add Repositories.

  7. Click Publish New Version and in the Description field, enter information about the version to log changes.

  8. Click Save.

  9. Optional: to force metadata regeneration on Yum repositories, from the Actions list for your Content View versions, select Regenerate Repository Metadata.

You can view the Content View in the Content Views window. To view more information about the Content View, click the Content View name.

To register a host to your Content View, see Registering Hosts in the Managing Hosts guide.

CLI procedure

  1. Obtain a list of repository IDs:

    # hammer repository list --organization "My_Organization"

  2. Create the Content View and add repositories:

    # hammer content-view create \
--description "My_Content_View" \
--name "My_Content_View" \
--organization "My_Organization" \
--repository-ids 1,2

    For the --repository-ids option, you can find the IDs in the output of the hammer repository list command.

  3. Publish the view:

    # hammer content-view publish \
--description "My_Content_View" \
--name "My_Content_View" \
--organization "My_Organization"

  4. Optional: To add a repository to an existing Content View, enter the following command:

    # hammer content-view add-repository \
--name "My_Content_View" \
--organization "My_Organization" \
--repository-id repository_ID

orcharhino Server creates the new version of the view and publishes it to the Library environment.

Best Practices for Content Views

  • There are two basic approaches to content views: Either create content views that contain everything needed for a certain type of host, for example a WebServer content view, which includes repositories for CentOS-8, Apache-2.0, and PostgreSQL-7.1. Alternatively, create a content view each for CentOS-8, Apache-2.0, and PostgreSQL-7.1 along with a composite content view WebServer, which includes all of these content views.

  • If you require daily updated content, use the content view Default Organization View. This contains the latest synchronized content from all repositories and is available in lifecycle environment Library.

  • Use content views and composite content views to assemble and structure lists of repositories. You can match different versions of content views or update specific content views when bundling them to a composite content view.

  • We recommend using composite content views only if you require more flexibility.

  • Making content management too small scale results in more manual work.

  • When using composite content views, publish the content views first, then the composite content views second. The more content views you bundle, the more work it becomes when making changes or updating content. We recommend making it as simple as possible and as complex as necessary.

  • Setting a lifecycle environment for content views is unnecessary if they are solely bundled to a composite content view.

  • Automate creating and publishing composite content views and lifecycle environments using Hammer scripts or Ansible Playbooks. Use cron jobs or recurring logics for more visibility. Recurring logics require SSH based access to orcharhino and the remote execution plugin.

  • We recommend adding the changes and date to the description of each published content view or composite content view version. The date shown in the management UI shows the latest action, for example promoting content to a different lifecycle environment, which is independent from the latest change to the actual content.

  • Publishing a new content view or composite content view creates a new major version. Incremental errata updates increment the minor version. Note that you cannot change or reset this counter.

Providing Content to Hosts

  • A content host receives content from your orcharhino Server or your orcharhino Proxies. It must be subscribed to orcharhino and is always associated to exactly one content view and exactly one lifecycle environment.

  • A subscription key consist of three parts: a lifecycle environment, a content view, and subscriptions. When you register a host using a given key, content is made available to the host.

  • Lifecycle environments describe the stage in which certain versions of content are available to hosts.

  • Content views are named and versioned collections of repositories.

For more information, see glossary.

Using Host Groups

  • A host group is a blueprint for both deploying hosts and managing existing hosts.

    • If you deploy a host using synced content as installation source, the lifecycle environment and content view are relevant for the content of the host.

    • For all other hosts, the content for the host depends on its activation key.

  • If you want to change the content a host is subscribed to, you need to resubscribe the host with a different activation key. Alternatively, you can change the lifecycle environment, content view, and subscriptions under Hosts > Content Hosts.

  • The information for an individual hosts displayed on Hosts > All Hosts is relevant if you want to re-build a host.

Viewing Module Streams

In orcharhino, you can view the module streams of the repositories in your Content Views.

Procedure

  1. In the orcharhino management UI, navigate to Content > Content Views, and select the Content View that contains the modules you want to view.

  2. Click the Versions tab and select the Content View version that you want to view.

  3. Click the Module Streams tab to view the module streams that are available for the Content View.

  4. Use the Filter field to refine the list of modules.

  5. To view the information about the module, click the module.

Promoting a Content View

Use this procedure to promote Content Views across different lifecycle environments. To use the CLI instead of the orcharhino management UI, see the CLI procedure.

Permission Requirements for Content View Promotion

Non-administrator users require two permissions to promote a Content View to an environment:

  1. promote_or_remove_content_views

  2. promote_or_remove_content_views_to_environment.

The promote_or_remove_content_views permission restricts which Content Views a user can promote.

The promote_or_remove_content_views_to_environment permission restricts the environments to which a user can promote Content Views.

With these permissions you can assign users permissions to promote certain Content Views to certain environments, but not to other environments. For example, you can limit a user so that they are permitted to promote to test environments, but not to production environments.

You must assign both permissions to a user to allow them to promote Content Views.

Procedure

  1. In the orcharhino management UI, navigate to Content > Content Views and select the Content View that you want to promote.

  2. Click the Versions tab for the Content View.

  3. Select the version that you want to promote and in the Actions column, click Promote.

  4. Select the environment where you want to promote the Content View, and click Promote Version.

  5. Click the Promote button again. This time select the Testing environment and click Promote Version.

  6. Finally click on the Promote button again. Select the Production environment and click Promote Version.

Now the repository for the Content View appears in all environments.

CLI procedure

  • Promote the Content View using the hammer content-view version promote each time:

    # hammer content-view version promote \
--content-view "Database" \
--version 1 \
--to-lifecycle-environment "Development" \
--organization "My_Organization"
# hammer content-view version promote \
--content-view "Database" \
--version 1 \
--to-lifecycle-environment "Testing" \
--organization "My_Organization"
# hammer content-view version promote \
--content-view "Database" \
--version 1 \
--to-lifecycle-environment "Production" \
--organization "My_Organization"

    Now the database content is available in all environments.

To register a host to your Content View, see Registering Hosts in the Managing Hosts guide.

Promoting a Content View Across All Life Cycle Environments within an Organization

Use this procedure to promote Content Views across all lifecycle environments within an organization.

Procedure

  1. To promote a selected Content View version from Library across all life cycle environments within an organization, run the following Bash script:

    ORG="My_Organization"
CVV_ID=3

for i in $(hammer --no-headers --csv lifecycle-environment list --organization $ORG | awk -F, {'print $1'} | sort -n)
do
   hammer content-view version promote --organization $ORG --to-lifecycle-environment-id $i --id $CVV_ID
done

  2. Display information about your Content View version to verify that it is promoted to the required lifecycle environments:

    # hammer content-view version info --id 3

Composite Content Views Overview

A Composite Content View combines the content from several Content Views. For example, you might have separate Content Views to manage an operating system and an application individually. You can use a Composite Content View to merge the contents of both Content Views into a new repository. The repositories for the original Content Views still exist but a new repository also exists for the combined content.

If you want to develop an application that supports different database servers. The example_application appears as:

example_software

Application

Database

Operating System

Example of four separate Content Views:

  • CentOS (Operating System)

  • PostgreSQL (Database)

  • MariaDB (Database)

  • example_software (Application)

From the previous Content Views, you can create two Composite Content Views.

Example Composite Content View for a PostgreSQL database:

Composite Content View 1 - example_software on PostgreSQL

example_software (Application)

PostgreSQL (Database)

CentOS (Operating System)

Example Composite Content View for a MariaDB:

Composite Content View 2 - example_software on MariaDB

example_software (Application)

MariaDB (Database)

CentOS (Operating System)

Each Content View is then managed and published separately. When you create a version of the application, you publish a new version of the Composite Content Views. You can also select the Auto Publish option when creating a Composite Content View, and then the Composite Content View is automatically republished when a Content View it includes is republished.

Repository Restrictions

You cannot include more than one of each repository in Composite Content Views. For example, if you attempt to include two Content Views using the same repository in a Composite Content View, orcharhino Server reports an error.

Creating a Composite Content View

Use this procedure to create a composite Content View. To use the CLI instead of the orcharhino management UI, see the CLI procedure.

Procedure

  1. In the orcharhino management UI, navigate to Content > Content Views and click Create New View.

  2. In the Name field, enter a name for the view. orcharhino automatically completes the Label field from the name you enter.

  3. In the Description field, enter a description of the view.

  4. Select the Composite View? check box to create a Composite Content View.

  5. Optional: select the Auto Publish check box if you want the Composite Content View to be republished automatically when a Content View is republished.

  6. Click Save.

  7. In the Add Content Views area, select the Content Views that you want to add to the Composite Content View, and then click Add Content Views.

  8. Click Publish New Version to publish the Composite Content View. In the Description field, enter a description and click Save.

  9. Click Promote and select the lifecycle environments to promote the Composite Content View to, enter a description, and then click Promote Version.

CLI procedure

  1. Before you create the Composite Content Views, list the version IDs for your existing Content Views:

    # hammer content-view version list \
--organization "My_Organization"

  2. Create a new Composite Content View. When the --auto-publish option is set to yes, the Composite Content View is automatically republished when a Content View it includes is republished:

    # hammer content-view create \
--composite \
--auto-publish yes \
--name "Example_Composite_Content_View" \
--description "Example Composite Content View" \
--organization "My_Organization"

  3. Add a component Content View to the Composite Content View. You must include the Content View Version ID and use the --latest option. To include multiple component Content Views to the Composite Content View, repeat this step for every Content View you want to include:

    # hammer content-view component add \
--component-content-view-id Content_View_Version_ID \
--latest \
--composite-content-view "Example_Composite_Content_View"

  4. Publish the Composite Content View:

    # hammer content-view publish \
--name "Example_Composite_Content_View" \
--description "Initial version of Composite Content View" \
--organization "My_Organization"

  5. Promote the Composite Content View across all environments:

    # hammer content-view version promote \
--content-view "Example_Composite_Content_View" \
--version 1 \
--to-lifecycle-environment "Development" \
--organization "My_Organization"
# hammer content-view version promote \
--content-view "Example_Composite_Content_View" \
--version 1 \
--to-lifecycle-environment "Testing" \
--organization "My_Organization"
# hammer content-view version promote \
--content-view "Example_Composite_Content_View" \
--version 1 \
--to-lifecycle-environment "Production" \
--organization "My_Organization"

Content Filter Overview

Content Views also use filters to include or restrict certain RPM and DEB content. Without these filters, a Content View includes everything from the selected repositories.

There are two types of content filters:

Table 1. Filter Types
Filter Type Description

Include

You start with no content, then select which content to add from the selected repositories. Use this filter to combine multiple content items.

Exclude

You start with all content from selected repositories, then select which content to remove. Use this filter when you want to use most of a particular content repository but exclude certain packages, such as blacklisted packages. The filter uses all content in the repository except for the content you select.
Include and Exclude Filter Combinations

If using a combination of Include and Exclude filters, publishing a Content View triggers the include filters first, then the exclude filters. In this situation, select which content to include, then which content to exclude from the inclusive subset.

Content Types

There are also five types of content to filter:

Table 2. Content Types
Content Type Description

Package

Filter packages based on their name and version number. The Package option filters non-modular RPM packages and errata.

Package Group

Filter packages based on package groups. The list of package groups is based on the repositories added to the Content View.

Erratum (by ID)

Select which specific errata to add to the filter. The list of Errata is based on the repositories added to the Content View.

Erratum (by Date and Type)

Select a issued or updated date range and errata type (Bugfix, Enhancement, or Security) to add to the filter.

Module Streams

Select whether to include or exclude specific module streams. The Module Streams option filters modular RPMs and errata, but does not filter non-modular content that is associated with the selected module stream.

Resolving Package Dependencies

In orcharhino, you can use the package dependency resolution feature to ensure that any dependencies that packages have within a Content View are added to the dependent repository as part of the Content View publication process.

You can select to resolve package dependencies for any Content View that you want, or you can change the default setting to enable or disable resolving package dependencies for all new Content Views.

Note that resolving package dependencies can cause significant delays to Content View promotion. The package dependency resolution feature does not consider packages that are installed on your system independently of the Content View or solve dependencies across repositories.

Resolving Package Dependencies and Filters

Filters do not resolve any dependencies of the packages listed in the filters. This might require some level of testing to determine what dependencies are required.

If you add a filter that excludes some packages that are required and the Content View has dependency resolution enabled, orcharhino ignores the rules you create in your filter in favor of resolving the package dependency.

If you create a content filter for security purposes, to resolve a package dependency, orcharhino can add packages that you might consider insecure.

Procedure

To resolve package dependencies by default, complete the following steps:

  1. In the orcharhino management UI, navigate to Administer > Settings and click the Content tab.

  2. Locate the Content View Dependency Solving Default, and select Yes.

You can also set the default level of dependency resolution that you want. You can select between adding packages to solve dependencies only if the required package does not exist, or to add the latest packages to resolve the dependency even if the package exists in the repository.

To set the default level of dependency resolution, complete the following steps:

  1. In the orcharhino management UI, navigate to Administer > Settings and click the Content tab.

  2. Locate the Content View Dependency Solving Algorithm and select one of the following options:

    • To add the package that resolves the dependency only if it does not exist in the repository, select Conservative.

    • To add the package that resolves the dependency regardless of whether or not it exists in the repository, select Greedy.

Content Filter Examples

Use any of the following examples with the procedure that follows to build custom content filters.

Example 1

Create a repository with the base CentOS packages. This filter requires a CentOS repository added to the Content View.

Filter:

  • Inclusion Type: Include

  • Content Type: Package Group

  • Filter: Select only the Base package group

Example 2

Create a repository that excludes all errata, except for security updates, after a certain date. This is useful if you want to perform system updates on a regular basis with the exception of critical security updates, which must be applied immediately. This filter requires a CentOS repository added to the Content View.

Filter:

  • Inclusion Type: Exclude

  • Content Type: Erratum (by Date and Type)

  • Filter: Select only the Bugfix and Enhancement errata types, and clear the Security errata type. Set the Date Type to Updated On. Set the Start Date to the date you want to restrict errata. Leave the End Date blank to ensure any new non-security errata is filtered.

Example 3

A combination of Example 1 and Example 2 where you only require the operating system packages and want to exclude recent bug fix and enhancement errata. This requires two filters attached to the same Content View. The Content View processes the Include filter first, then the Exclude filter.

Filter 1:

  • Inclusion Type: Include

  • Content Type: Package Group

  • Filter: Select only the Base package group

Filter 2:

  • Inclusion Type: Exclude

  • Content Type: Erratum (by Date and Type)

  • Filter: Select only the Bugfix and Enhancement errata types, and clear the Security errata type. Set the Date Type to Updated On. Set the Start Date to the date you want to restrict errata. Leave the End Date blank to ensure any new non-security errata is filtered.

Example 4

Filter a specific module stream in a Content View.

Filter 1:

  • Inclusion Type: Include

  • Content Type: Module Stream

  • Filter: Select only the specific module stream that you want for the Content View, for example ant, and click Add Module Stream.

Filter 2:

  • Inclusion Type: Exclude

  • Content Type: Package

  • Filter: Add a rule to filter any non-modular packages that you want to exclude from the Content View. If you do not filter the packages, the Content View filter includes all non-modular packages associated with the module stream ant. Add a rule to exclude all * packages, or specify the package names that you want to exclude.

Creating a Content Filter for Yum Content

You can filter Content Views containing Yum content to include or exclude specific packages, package groups, errata, or module streams. Filters are based on a combination of the name, version, and architecture.

To use the CLI instead of the orcharhino management UI, see the CLI procedure.

For examples of how to build a filter, see Content Filter Examples.

Procedure

  1. In the orcharhino management UI, navigate to Content > Content Views and select a Content View.

  2. Select Yum Content > Filters and click New Filter.

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

  4. From the Content Type list, select the content type that you want to filter. Depending on what you select for the new filter’s content type, different options appear.

  5. From the Inclusion Type list, select either Include or Exclude.

  6. Optional: In the Description field, enter a description for the filter.

  7. Click Save to create your content filter.

  8. Depending on what you enter for Content Type, add rules to create the filter that you want.

  9. Click the Affected repositories tab to select which specific repositories use this filter.

  10. Click Publish New Version to publish the filtered repository.

  11. Optional: In the Description field, enter a description of the changes.

  12. Click Save to publish a new version of the Content View.

    You can promote this Content View across all environments.

CLI procedure

  1. Add a filter to the Content View. Use the --inclusion false option to set the filter to an Exclude filter:

    # hammer content-view filter create \
--name "Errata Filter" \
--type erratum --content-view "Example_Content_View" \
--description "My latest filter" \
--inclusion false \
--organization "My_Organization"

  2. Add a rule to the filter:

    # hammer content-view filter rule create \
--content-view "Example_Content_View" \
--content-view-filter "Errata Filter" \
--start-date "YYYY-MM-DD" \
--types enhancement,bugfix \
--date-type updated \
--organization "My_Organization"

  3. Publish the Content View:

    # hammer content-view publish \
--name "Example_Content_View" \
--description "Adding errata filter" \
--organization "My_Organization"

  4. Promote the view across all environments:

    # hammer content-view version promote \
--content-view "Example_Content_View" \
--version 1 \
--to-lifecycle-environment "Development" \
--organization "My_Organization"
# hammer content-view version promote \
--content-view "Example_Content_View" \
--version 1 \
--to-lifecycle-environment "Testing" \
--organization "My_Organization"
# hammer content-view version promote \
--content-view "Example_Content_View" \
--version 1 \
--to-lifecycle-environment "Production" \
--organization "My_Organization"

The text and illustrations on this page are licensed by ATIX AG under a Creative Commons Attribution–Share Alike 3.0 Unported ("CC-BY-SA") license. This page also contains text from the official Foreman documentation which uses the same license ("CC-BY-SA").