Managing content views

orcharhino uses content views to allow your hosts access to a deliberately curated subset of content. To do this, you must define which repositories to use and then apply certain filters to the content.

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. Optional: Create one or more filters to refine the content of the content view. For more information, see Content Filter Examples.

  4. Optional: Resolve any package dependencies for a content view. For more information, see Resolving Package Dependencies.

  5. Publish the content view.

  6. Optional: Promote the content view to another environment. For more information, see Promoting a Content View.

  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.

Content views in orcharhino

A content view is a deliberately curated subset of content that your hosts can access. By creating a content view, you can define the software versions used by a particular environment or orcharhino Proxy Server.

Each content view creates a set of repositories across each environment. Your orcharhino Server stores and manages these repositories. For example, you can create content views in the following ways:

  • A content view with older package versions for a production environment and another content view with newer package versions for a Development environment.

  • A content view with a package repository required by an operating system and another content view with a package repository required by an application.

  • A composite content view for a modular approach to managing content views. For example, you can use one content view for content for managing an operating system and another content view for content for managing an application. By creating a composite content view that combines both content views, you create a new repository that merges the repositories from each of the content views. However, the repositories for the content views still exist and you can keep managing them separately as well.

Default Organization View

A Default Organization View is an application-controlled content view for all content that is synchronized to orcharhino. You can register a host to the Library environment on orcharhino to consume the Default Organization View without configuring content views and lifecycle environments.

You can access unprotected repositories in the Default Organization View content view. The URL consists of your orcharhino Proxy FQDN, /pulp/content/, your organization label, /Library/custom/, your product label, /, your repository label, and a trailing /, for example, https://orcharhino.example.com/pulp/content/Example/Library/custom/Red_Hat_Enterprise_Linux_9/BaseOS/. For more information, see Adding Custom RPM Repositories.

Promoting a content view across environments

When you promote a content view from one environment to the next environment in the application lifecycle, orcharhino updates the repository and publishes the packages.

Example 1. Promoting a package from Development to Testing

The repositories for Testing and Production contain the my-software-1.0-0.noarch.rpm package:

Development Testing Production

Version of the content view

Version 2

Version 1

Version 1

Contents of the content view

my-software-1.1-0.noarch.rpm

my-software-1.0-0.noarch.rpm

my-software-1.0-0.noarch.rpm

If you promote Version 2 of the content view from Development to Testing, the repository for Testing updates to contain the my-software-1.1-0.noarch.rpm package:

Development Testing Production

Version of the content view

Version 2

Version 2

Version 1

Contents of the content view

my-software-1.1-0.noarch.rpm

my-software-1.1-0.noarch.rpm

my-software-1.0-0.noarch.rpm

This ensures hosts are designated to a specific environment but receive updates when that environment uses a new version of the content view.

With Distribute archived content view versions enabled, you can access unprotected repositories in published content view versions. The URL consists of your orcharhino Proxy FQDN, /pulp/content/, your organization label, /content_views/, your content view, your content view version, /custom/, your product label, /, your repository label, and a trailing /, for example, https://orcharhino.example.com/pulp/content/Example/content_views/Red_Hat_Enterprise_Linux_9/2.1/custom/Red_Hat_Enterprise_Linux_9/BaseOS/.

If you want to access the latest published content view, the URL consists of your orcharhino Proxy FQDN, /pulp/content/, your organization label, your lifecycle, your content view, /custom/, your product label, /, your repository label, and a trailing /, for example, https://orcharhino.example.com/pulp/content/Example/Production/Red_Hat_Enterprise_Linux_9/custom/Red_Hat_Enterprise_Linux_9/Red_Hat_Enterprise_Linux_9/.

You can use these URLs to provide versioned orcharhino Client for Red Hat Enterprise Linuxs during host registration.

Best practices for content views

  • Content views that bundle content, such as Red Hat Enterprise Linux and additional software like Apache-2.4 or PostgreSQL-16.2, are easier to maintain. Content views that are too small require more maintenance."

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

  • Restrict composite content views to situations that require greater flexibility, for example, if you update one content view on a weekly basis and another content view on a monthly basis.

  • If you use composite content views, first publish the content views and then publish the composite content views. The more content views you bundle into composite content views, the more effort is needed to change or update content.

  • 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 by using a Hammer script or an Ansible Playbook. Use cron jobs, systemd timers, or recurring logics for more visibility.

  • Add the changes and date to the description of each published content view or composite content view version. The most recent activity, such as moving content to a new lifecycle environment, is displayed by date in the orcharhino management UI, regardless of the latest changes to the content itself.

  • 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.

Best practices for patching content hosts

  • Registering hosts to orcharhino requires orcharhino Client for Red Hat Enterprise Linux, which contains the subscription-manager package, katello-host-tools package, and their dependencies. For more information, see Registering hosts in Managing Hosts.

  • Use the orcharhino management UI to install, upgrade, and remove packages from hosts. You can update content hosts with job templates using SSH and Ansible.

  • Apply errata on content hosts using the orcharhino management UI. When patching packages on hosts using the default package manager, orcharhino receives a list of packages and repositories to recalculate applicable errata and available updates.

  • Modify or replace job templates to add custom steps. This allows you to run commands or execute scripts on hosts.

  • When running bulk actions on hosts, bundle them by major operating system version, especially when upgrading packages.

  • Select via remote execution – customize first to define the time when patches are applied to hosts when performing bulk actions.

  • You cannot apply errata to packages that are not part of the repositories on orcharhino and the attached content view.

  • Modifications to installed packages using rpm or dpkg are sent to orcharhino with the next run of apt, yum, or zypper.

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 > Lifecycle > Content Views.

  2. Click Create content view.

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

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

  5. In the Type field, select a Content view or a Composite content view.

  6. Optional: If you want to solve dependencies automatically every time you publish this content view, select the Solve dependencies checkbox. 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.

  7. Click Create content view.

Content view steps

  1. Click Create content view to create the content view.

  2. In the Repositories tab, select the repository from the Type list that you want to add to your content view, select the checkbox next to the available repositories you want to add, then click Add repositories.

  3. Click Publish new version and in the Description field, enter information about the version to log changes.

  4. Optional: You can enable a promotion path by clicking Promote to Select a lifecycle environment from the available promotion paths to promote new version.

  5. Click Next.

  6. On the Review page, you can review the environments you are trying to publish.

  7. Click Finish.

You can view the content view on the Content Views page. 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 Managing Hosts.

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.

Copying a content view

You can copy a content view in the orcharhino management UI or you can use the Hammer CLI to copy an existing content view into a new content view. To use the CLI instead of the orcharhino management UI, see the CLI procedure.

A copied content view does not have the same history as the original content view. Version 1 of the copied content view begins at the last version of the original content view. As a result, you cannot promote an older version of a content view from the copied content view.
Procedure

  1. In the orcharhino management UI, navigate to Content > Lifecycle > Content Views.

  2. Select the content view you want to copy.

  3. Click the vertical ellipsis icon and click Copy.

  4. In the Name field, enter a name for the new content view and click Copy content view.

Verification

  • The copied content view appears on the Content views page.

CLI procedure

  • Copy the content view by using Hammer:

    $ hammer content-view copy --name My_original_CV_name \
--new-name My_new_CV_name
Verification

  • The Hammer command reports:

$ hammer content-view copy --id=5 --new-name="mixed_copy"
Content view copied.
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.

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

Procedure

  1. In the orcharhino management UI, navigate to a published version of a Content View > Module Streams to view the module streams that are available for the Content Types.

  2. Use the Search field to search for specific modules.

  3. To view the information about the module, click the module and its corresponding tabs to include Details, Repositories, Profiles, and Artifacts.

CLI procedure

  1. List all organizations:

    $ hammer organization list

  2. View all module streams for your organization:

    $ hammer module-stream list \
--organization-id My_Organization_ID

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 > Lifecycle > Content Views.

  2. Select the content view that you want to promote.

  3. Select the version that you want to promote, click the vertical ellipsis icon, and click Promote.

  4. Select the environment where you want to promote the content view and click Promote.

Now the repository for the content view appears in all environments.

CLI procedure

  • Promote the content view using Hammer for each lifecycle environment:

    $ 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.

  • Alternatively, you can promote content views across all lifecycle environments within an organization using the following Bash script:

    ORG="My_Organization"
CVV_ID=My_Content_View_Version_ID

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
Verification

  • Display information about your content view version to verify that it is promoted to the required lifecycle environments:

    $ hammer content-view version info --id My_Content_View_Version_ID
Next steps

Rolling content views

A rolling content view is a curated subset of content that your hosts can access. It is a subset of the Library environment and contains the latest synchronized content from one or multiple repositories. You can use a rolling content view to provide a continuous stream of synchronized content to hosts.

When you synchronize repositories to orcharhino, all rolling content views that contain them get automatically updated to include the latest changes. You do not have to publish and/or promote a rolling content view compared to content views or composite content views.

Creating a rolling content view

Use this procedure to create a rolling 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 > Lifecycle > Content Views.

  2. Click Create content view.

  3. In the Create content view window, enter a name for the content view in the Name field. orcharhino automatically completes the Label field from the name you enter.

  4. Optional: In the Description field, enter a description of the content view.

  5. On the Type tab, select Rolling content view.

  6. Click Create content view.

  7. In the Repositories tab, select All from the Status list.

  8. Select the repositories that you want to add to your rolling content view.

  9. Click Add repositories to add all selected repositories to your rolling content view.

CLI procedure

  1. Before you create a rolling content views, list all available repositories:

    $ hammer repository list \
--fields id,name,product \
--organization "My_Organization"

  2. Create your rolling content view:

    $ hammer content-view create \
--name "My_Rolling_Content_View" \
--organization "My_Organization" \
--repository-ids My_List_Of_Repository_IDs \
--rolling
Next steps

  • You cannot publish and promote your rolling content view. Instead, continue with by adding it to your activation key. For more information, see Creating an Activation Key.

  • To register a host to your rolling content view, see Registering Hosts in Managing Hosts.

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:

  • Red Hat Enterprise Linux (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)

Red Hat Enterprise Linux (Operating System)

Example composite content view for a MariaDB:

Composite content view 2 – example_software on MariaDB

example_software (Application)

MariaDB (Database)

Red Hat Enterprise Linux (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

Docker repositories cannot be included more than once in a composite content view. For example, if you attempt to include two content views using the same docker 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 > Lifecycle > Content Views.

  2. Click Create content view.

  3. In the Create content view window, enter a name for the view in the Name field. orcharhino automatically completes the Label field from the name you enter.

  4. Optional: In the Description field, enter a description of the view.

  5. On the Type tab, select Composite content view.

  6. Optional: If you want to automatically publish a new version of the composite content view when a content view is republished, select the Auto publish checkbox.

  7. Click Create content view.

  8. On the Content views tab, select the content views that you want to add to the composite content view, and then click Add content views.

  9. In the Add content views window, select the version of each content view.

  10. Optional: If you want to automatically update the content view to the latest version, select the Always update to latest version checkbox.

  11. Click Add, then click Publish new version.

  12. Optional: In the Description field, enter a description of the content view.

  13. In the Publish window, set the Promote switch, then select the lifecycle environment.

  14. Click Next, then click Finish.

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 content view to the composite content view. You can identify content view, content view version, and Organization in the commands by either their ID or their name. To add multiple content views to the composite content view, repeat this step for every content view you want to include.

    • If you have the Always update to latest version option enabled for the content view:

      $ hammer content-view component add \
--component-content-view-id Content_View_ID \
--composite-content-view "Example_Composite_Content_View" \
--latest \
--organization "My_Organization"

    • If you have the Always update to latest version option disabled for the content view:

      $ hammer content-view component add \
--component-content-view-id Content_View_ID \
--composite-content-view "Example_Composite_Content_View" \
--component-content-view-version-id Content_View_Version_ID \
--organization "My_Organization"

  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 Deb and Yum 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 while excluding certain 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

You can filter content based on the following content types:

Table 2. Content types
Content Type Description

RPM

Filter packages based on their name and version number. The RPM option filters non-modular RPM packages and errata. Source RPMs are not affected by this filter and will still be available in the content view.

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.

Container Image Tag

Select whether to include or exclude specific container image tags.

Resolving package dependencies

orcharhino can add dependencies of packages in a content view to the dependent repository when publishing the content view. To configure this, you can enable dependency solving.

For example, dependency solving is useful when you incrementally add a single package to a content view version. You might need to enable dependency solving to install that package.

However, dependency solving is unnecessary in most situations. For example:

  • When incrementally adding a security errata to a content view, dependency solving can cause significant delays to content view publication without major benefits.

  • Packages from a newer erratum might have dependencies that are incompatible with packages from an older content view version. Incrementally adding the erratum using dependency solving might include unwanted packages. As an alternative, consider updating the content view.

Dependency solving only considers packages within the repositories of the content view. It does not consider packages installed on clients. For example, if a content view includes only AppStream, dependency solving does not include dependent BaseOS content at publish time.

For more information, see Limitations to Repository Dependency Resolution in Managing Content.

Dependency solving can lead to the following problems:

Significant delay in content view publication

orcharhino examines every repository in a content view for dependencies. Therefore, publish time increases with more repositories.

To mitigate this problem, use multiple content views with fewer repositories and combine them into composite content views.

Ignored content view filters on dependent packages

orcharhino prioritizes resolving package dependencies over the rules in your filter.

For example, if you create a filter for security purposes but enable dependency solving, orcharhino can add packages that you might consider insecure.

To mitigate this problem, carefully test filtering rules to determine the required dependencies. If dependency solving includes unwanted packages, manually identify the core basic dependencies that the extra packages and errata need.

Example 2. Combining exclusion filters with dependency solving

You want to recreate Red Hat Enterprise Linux 8.3 using content view filters and include selected errata from a later Red Hat Enterprise Linux 8 minor release. To achieve this, you create filters to exclude most of the errata after the Red Hat Enterprise Linux 8.3 release date, except a few that you need. Then, you enable dependency solving.

In this situation, dependency solving might include more packages than expected. As a result, the host diverges from being a Red Hat Enterprise Linux 8.3 machine.

If you do not need the extra errata and packages, do not configure content view filtering. Instead, enable and use the Red Hat Enterprise Linux 8.3 repository on the Content > Red Hat Repositories page in the orcharhino management UI.

Example 3. Excluding packages sometimes makes dependency solving impossible for DNF

If you make a Red Hat Enterprise Linux 8.3 repository with a few excluded packages, dnf upgrade can sometimes fail.

Do not enable dependency solving to resolve the problem. Instead, investigate the error from dnf and adjust the filters to stop excluding the missing dependency.

Else, dependency solving might cause the repository to diverge from Red Hat Enterprise Linux 8.3.

Enabling dependency solving for a content view

Use this procedure to enable dependency solving for a content view.

Prerequisites
Procedure

  1. In the orcharhino management UI, navigate to Content > Lifecycle > Content Views.

  2. From the list of content views, select the required content view.

  3. On the Details tab, toggle Solve dependencies.

Content filter examples

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

Filters can significantly increase the time to publish a content view. For example, if a content view publish task completes in a few minutes without filters, it can take 30 minutes after adding an exclude or include errata filter.
Example 1

Create a repository with the base Red Hat Enterprise Linux packages. This filter requires a Red Hat Enterprise Linux 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 Red Hat Enterprise Linux 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 > Lifecycle > Content Views.

  2. Select a content view.

  3. On the Filters tab, click Create filter.

  4. Enter a name.

  5. From the Content type list, select a content type.

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

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

  8. Click Create filter to create your content filter.

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

  10. Select if you want the filter to Apply to subset of repositories or Apply to all repositories.

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

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

  13. Click Create filter 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"

Deleting multiple content view versions

You can delete multiple content view versions simultaneously.

Procedure

  1. In the orcharhino management UI, navigate to Content > Lifecycle > Content Views.

  2. Select the content view you want to delete versions of.

  3. On the Versions tab, select the checkbox of the version or versions you want to delete.

  4. Click the vertical ellipsis icon at the top of the list of content views.

  5. Click Delete to open the deletion wizard that shows any affected environments.

  6. If there are no affected environments, review the details and click Delete.

  7. If there are any affected environments, reassign any hosts or activation keys before deletion.

  8. Review the details of the actions.

  9. Click Delete.

Clearing the search filter

If you search for specific content types using keywords in the Search text box and the search returns no results, click Clear search to clear all the search queries and reset the Search text box.

If you use a filter to search for specific repositories in the Type text box and the search returns no results, click Clear filters to clear all active filters and reset the Type text box.

Standardizing content view empty states

If there are no filters listed for a content view, click Create filter. A modal opens to show you the next steps to create a filter. Follow these steps to add a new filter to create new content types.

Comparing content view versions

Use this procedure to compare content view version functionality for orcharhino.

Procedure

  1. In the orcharhino management UI, navigate to Content > Lifecycle > Content Views.

  2. Select a content view whose versions you want to compare.

  3. On the Versions tab, select the checkbox next to any two versions you want to compare.

  4. Click Compare.

    The Compare screen has the pre-selected versions in the version dropdown menus and tabs for all content types found in either version. You can filter the results to show only the same, different, or all content types. You can compare different content view versions by selecting them from the dropdown menus.

Distributing archived content view versions

The setting Distribute archived content view versions enables hosting of non-promoted content view version repositories in the orcharhino content web application along with other repositories. This is useful while debugging to see what content is present in your content view versions.

Procedure

  1. In the orcharhino management UI, navigate to Administer > Settings.

  2. Click the Content tab.

  3. Set the Distribute archived content view versions parameter to Yes.

  4. Click Submit.

    This enables the repositories of content view versions without lifecycle environments to be distributed at orcharhino.example.com/pulp/content/My_Organization/content_views/My_Content_View/My_Content_View_Version/.

    Older non-promoted content view versions are not distributed once the setting is enabled. Only new content view versions become distributed.

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