Managing content views and content view environments

Use content views to curate the content that hosts consume. You can create and promote content views, configure filters, work with rolling and composite views, manage versions, and assign content view environments to hosts.

Workflow for creating content views

Follow this sequence to add repositories, optionally refine content with filters and dependency resolution, publish and promote the content view, and attach hosts.

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.

  4. Optional: Resolve any package dependencies for a content view.

  5. Publish the content view.

  6. Optional: Promote the content view to another environment.

  7. Attach the host to the content view.

    If a repository is not associated with the content view, the file /etc/apt/sources.list.d/rhsm.sources remains empty and hosts 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.

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.

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/Ubuntu_26.04/resolute-main/.

    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.all.deb 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.all.deb

my-software-1.0-0.all.deb

my-software-1.0-0.all.deb

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.all.deb 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.all.deb

my-software-1.1-0.all.deb

my-software-1.0-0.all.deb

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/Ubuntu_26.04/2.1/custom/Ubuntu_26.04/resolute-main/.

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/Ubuntu_26.04/custom/Ubuntu_26.04/Ubuntu_26.04/.

You can use these URLs to provide versioned orcharhino Client for Ubuntus during host registration.

You can consume content from orcharhino without registering your hosts to orcharhino and/or without using subscription-manager to consume content, for example, in containerized build pipelines. Any host that consumes content from orcharhino Server or orcharhino Proxy Servers is considered a managed host that requires a valid orcharhino subscription.

Best practices for content views

ATIX AG recommends you apply these practices when you plan, publish, and maintain content views to reduce administrative overhead and keep host content consistent.

  • Content views that bundle content, such as Ubuntu 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.

  • If you require daily updated content for hosts registered to a specific orcharhino Proxy Server, use rolling content views and assign them to a lifecycle environment other than Library.

  • To give hosts access to content from multiple content views, such as when you update one content view weekly and another monthly, you have two options:

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

Creating a content view by using orcharhino management UI

Create a content view to define which repositories and content your hosts can access through lifecycle environments.

Prerequisites
  • At least one repository is available in your organization.

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. Click Create content view.

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

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

  9. Optional: Enable a promotion path by clicking Promote and select one or more lifecycle environments to promote the new version to.

  10. Click Next.

  11. On the Review details page, review the environments you are trying to publish.

  12. Click Finish.

Next steps

Creating a content view by using Hammer CLI

Create a content view to define which repositories and content your hosts can access through lifecycle environments.

Prerequisites
  • At least one repository is available in your organization.

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 My_Repository_ID_1,My_Repository_ID_2
  3. Optional: Add another repository to your content view:

    $ hammer content-view add-repository \
    --name "My_Content_View" \
    --organization "My_Organization" \
    --repository-id My_Repository_ID_3
  4. Publish the content view:

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

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

Copying a content view by using orcharhino management UI

Copy an existing content view to create a content view based on its repositories and filters without reconfiguring them from scratch.

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. Open the options menu 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.

Copying a content view by using Hammer CLI

Copy an existing content view to create a content view based on its repositories and filters without reconfiguring them from scratch.

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
  • Copy the content view by using Hammer:

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

Synchronizing a content view to a orcharhino Proxy Server

In the orcharhino management UI, you can only synchronize all selected lifecycle environments simultaneously. If you need to synchronize smaller items, such as individual lifecycle environments, single content views, and single repositories, use the Hammer CLI.

Prerequisites
  • The content view is published and promoted to a lifecycle environment that the orcharhino Proxy Server synchronizes.

Procedure
  • Synchronize a content view to your orcharhino Proxy Server:

    $ hammer proxy content synchronize \
    --content-view "My_Content_View_Name" \
    --id My_orcharhino_Proxy_Server_ID

Promoting a content view by using orcharhino management UI

Promote a content view to the next lifecycle environment to make its published content available to hosts in that environment.

Prerequisites
  • Your orcharhino account has a role that grants the promote_or_remove_content_views and promote_or_remove_content_views_to_environment permissions.

  • The content view has at least one published version.

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 options icon, and click Promote.

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

Next steps

Promoting a content view by using Hammer CLI

Promote a content view to the next lifecycle environment to make its published content available to hosts in that environment.

Prerequisites
  • Your orcharhino account has a role that grants the promote_or_remove_content_views and promote_or_remove_content_views_to_environment permissions.

  • The content view has at least one published version.

Procedure
  • Promote the content view to a lifecycle environment:

    $ hammer content-view version promote \
    --content-view "My_Content_View_Name" \
    --version 1 \
    --to-lifecycle-environment "My_Lifecycle_Environment_Name" \
    --organization "My_Organization"

    Repeat the command for each lifecycle environment to promote the content view to.

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

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

Promoting a content view to all environments in an organization

You can promote content views across all lifecycle environments within an organization by using the following Bash script.

Prerequisites
  • Your orcharhino account has a role that grants the promote_or_remove_content_views and promote_or_remove_content_views_to_environment permissions.

  • The content view version that you want to promote is published.

Procedure
  • Promote content views across all lifecycle environments within an organization:

    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

Configuring content view filters

After you add repositories to a content view, you can refine what content hosts receive by configuring include and exclude filters and optional dependency resolution.

Content filter overview

Use content view filters to include or exclude specific Deb and Yum packages, errata, and other content types from a published view. Without filters, a content view includes all content from its selected repositories.

Filter types

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

Deb

Filter packages based on their name. The Deb option filters Deb packages.

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.

Container Image Tag

Select whether to include or exclude specific container image tags.

Content filter examples

These examples show common content filter configurations for package groups and errata that you can adapt when refining a content view.

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 2. Include a package group

Create a repository with the base Ubuntu packages. This filter requires a Ubuntu repository added to the content view.

Filter:

  • Inclusion Type: Include

  • Content Type: Package Group

  • Filter: Select only the Base package group

Example 3. Exclude errata

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 Ubuntu 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 4. Exclude errata and include a package group

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.

Creating a content view filter by using orcharhino management UI

Create content view filters to include or exclude specific packages, errata, and other content types from a content view. Package filters match content by name, version, and architecture.

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

Prerequisites
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. Click Add Deb rule.

  10. Enter a name, architecture, and version.

  11. Click Add rule.

  12. Select if you want the filter to Apply to subset of repositories or Apply to all repositories in the CV.

  13. Click Publish new version to publish the filtered content view.

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

  15. Optional: Select Promote to promote your filtered content view to a lifecycle environment.

  16. Click Finish to publish a new version of the content view.

Creating a content view filter by using CLI

You can use Hammer CLI to create content view filters to include or exclude specific content units like packages, errata, or container image tags.

Prerequisites
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"

Managing content view versions

Each time you publish a content view, orcharhino creates a new version. You can compare versions to review changes, delete unused versions to reclaim storage, and distribute archived versions for debugging.

Comparing content view versions

Compare two content view versions to identify added, removed, or changed packages, errata, and other content between versions.

Prerequisites
  • The content view has at least two published versions.

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

Enable distribution of archived content view versions when you need access to repositories from published versions that are not currently promoted, such as for debugging.

Prerequisites
  • Your orcharhino account has a role that grants the view_settings and edit_settings permissions.

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.

Deleting multiple content view versions by using orcharhino management UI

Delete multiple content view versions at once to remove obsolete snapshots and free storage on orcharhino Server.

Prerequisites
  • Your orcharhino account has a role that grants the promote_or_remove_content_views permission.

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. Open the options menu 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.

Deleting multiple content view versions by using Hammer CLI

You can delete multiple content view versions simultaneously by using Hammer CLI.

Procedure
  1. List versions of your content view:

    $ hammer content-view info \
    --name "My_Content_View_Name" \
    --organization-id My_Organization_ID
  2. Delete content view versions:

    $ hammer content-view remove \
    --content-view-version-ids My_Content_View_Version_ID_1,My_Content_View_Version_ID_2 \
    --id My_Content_View_ID
Verification
  • Verify that orcharhino deleted the content view versions:

    $ hammer content-view info \
    --name "My_Content_View_Name" \
    --organization-id My_Organization_ID

Deleting multiple content view versions by using Ansible

You can delete multiple content view versions simultaneously by using orcharhino Ansible collection.

Procedure
  • Use the "`theforeman.foreman`".content_view_version module.

    For more information, see the Ansible module documentation with ansible-doc "`theforeman.foreman`".content_view_version.

Purging content view versions by using Hammer CLI

You can purge excess numbers of content view versions on orcharhino to limit disk space usage. By default, orcharhino keeps every version of a content view. Removing content view versions is a tradeoff between disk space and possibly bandwidth during content synchronizations to orcharhino Proxy Servers and the possibility to roll back to older content snapshots.

orcharhino only considers deleting content view versions that are not part of any lifecycle environment.

Procedure
  1. Optional: View your content view versions:

    $ hammer content-view info \
    --name "My_Content_View_Name" \
    --organization-id My_Organization_ID
  2. Clean up content view versions:

    $ hammer content-view purge \
    --name "My_Content_View_Name" \
    --organization-id My_Organization_ID \
    --versions-to-keep My_Number_Of_Versions_To_Keep
Verification
  • Verify that orcharhino deleted the content view versions:

    $ hammer content-view info \
    --name "My_Content_View_Name" \
    --organization-id My_Organization_ID

Using composite content views

Use composite content views when you need to merge content from multiple content views for hosts to consume.

Composite content views overview

A composite content view combines repositories from several content views for hosts to consume content. Use it when hosts need content from multiple content views, such as an operating system and an application, managed separately.

Example 5. Application that supports different database servers

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:

  • Ubuntu (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)

Ubuntu (Operating System)

Example composite content view for a MariaDB:

Composite content view 2 – example_software on MariaDB

example_software (Application)

MariaDB (Database)

Ubuntu (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 that contain the same docker repository in a composite content view, orcharhino Server reports an error.

Creating a composite content view by using orcharhino management UI

Create a composite content view to combine repositories from multiple content views for your hosts to consume.

Prerequisites
  • The content views that you want to combine are published.

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.

Creating a composite content view by using Hammer CLI

Create a composite content view to combine repositories from multiple content views for your hosts to consume.

Prerequisites
  • The content views that you want to combine are published.

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"

Using rolling content views

Use rolling content views when you need hosts to consume the latest synchronized content without publishing and promoting new content view versions.

Rolling content views

A rolling content view is a curated subset of Library content that hosts can access without publishing or promoting new content view versions. Use it to provide a continuous stream of the latest synchronized content from one or more repositories.

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.

Instead, you can assign rolling content views to one or multiple lifecycle environments. By doing so, you can synchronize subsets of the Library content from orcharhino Server to orcharhino Proxy Servers that are configured to consume content from the assigned lifecycle environments.

Creating a rolling content view by using orcharhino management UI

Create a rolling content view to give hosts continuous access to the latest synchronized content without publishing new content view versions.

Prerequisites
  • At least one populated repository exists in your organization.

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. Optional: In the Lifecycle Environments field, assign your rolling content view to your lifecycle environments.

  7. Click Create content view.

  8. Click Show repositories.

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

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

Next steps

Creating a rolling content view by using Hammer CLI

Create a rolling content view to give hosts continuous access to the latest synchronized content without publishing new content view versions.

Prerequisites
  • At least one repository is synchronized to your organization.

Procedure
  1. List all available lifecycle environments:

    $ hammer lifecycle-environment list \
    --fields id,name \
    --organization "My_Organization"
  2. List all available repositories to identify IDs of repositories to add to your rolling content view:

    $ hammer repository list \
    --fields id,name,product \
    --organization "My_Organization"
  3. Create your rolling content view:

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

Assigning a rolling content view to lifecycle environments by using orcharhino management UI

Assign a rolling content view to lifecycle environments to limit which Library content is synchronized to orcharhino Proxy Servers.

To consume rolling content views, you must assign them to one or more lifecycle environments. By doing so, you expose a subset of Library content to those lifecycle environments. ATIX AG does not recommend assigning a rolling content view to the Library environment itself because it creates duplicate content within Library. By using environments other than Library, you can synchronize your rolling content views from orcharhino Server to any orcharhino Proxy Servers that are configured to consume the relevant lifecycle environments without the need to synchronize all of Library to orcharhino Proxy Servers.

Prerequisites
  • A rolling content view exists in your organization.

  • At least one lifecycle environment other than Library exists in your organization.

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

  2. Select your rolling content view.

  3. Select the Details tab.

  4. In the Lifecycle Environments field, assign your rolling content view to your lifecycle environments.

  5. Click Save Environments to submit your changes to orcharhino.

Next steps
  • Synchronize lifecycle environments to orcharhino Proxy Servers.

Assigning a rolling content view to lifecycle environments by using Hammer CLI

Assign a rolling content view to lifecycle environments to limit which Library content is synchronized to orcharhino Proxy Servers.

To consume rolling content views, you must assign them to one or more lifecycle environments. By doing so, you expose a subset of Library content to those lifecycle environments. ATIX AG does not recommend assigning a rolling content view to the Library environment itself because it creates duplicate content within Library. By using environments other than Library, you can synchronize your rolling content views from orcharhino Server to any orcharhino Proxy Servers that are configured to consume the relevant lifecycle environments without the need to synchronize all of Library to orcharhino Proxy Servers.

Prerequisites
  • A rolling content view exists in your organization.

  • At least one lifecycle environment other than Library exists in your organization.

Procedure
  1. List all content views:

    $ hammer content-view list \
    --fields "content view id,name" \
    --organization "My_Organization"
  2. Assign your rolling content view to lifecycle environments:

    $ hammer content-view update \
    --id My_Rolling_Content_View_ID \
    --lifecycle-environment-ids My_List_Of_Lifecycle_Environment_IDs \
    --organization "My_Organization"

    If you want to remove your rolling content view from all lifecycle environments, pass an empty list.

Next steps

Managing content view environments

A content view environment combines a lifecycle environment and a content view into a single entity. You can assign hosts to content view environments, control multi-environment access, and set content view priority.

Content view environments overview

By default, you can assign multiple content view environments to hosts and activation keys. This is controlled by the Allow multiple content views setting.

Hosts registered with multiple activation keys handle content view environment assignments based on the order of activation keys and content view environments.

When you disable Allow multiple content views, multi-environment hosts remain assigned to multiple content view environments and retain access to all their content. Existing multi-environment activation keys remain associated with multiple content view environments, and both multi-environment hosts and activation keys remain visible in the orcharhino management UI and accessible through the Hammer CLI. However, registration fails if you attempt to assign a host to multiple content view environments or use a multi-environment activation key during host registration. Assigning multiple content view environments to a host or activation key results in an error.

When you disable Allow multiple content views, you can still reassign a multi-environment host to a single content view environment. You can also reassign a multi-environment activation key to a single content view environment or remove all content view environments from the key.

Content view environment categories

orcharhino labels content view environments according to the lifecycle environment and content view they represent.

The content view environments available in your organization fall into the following categories:

Library environment

orcharhino assigns the Library environment to represent the Library lifecycle environment and the Default Organization View content view. orcharhino labels this environment as Library.

Unpromoted content views

For each content view that you publish but do not promote to a lifecycle environment, orcharhino creates a content view environment. orcharhino labels these environments using the format: Library/<content_view_label>.

Promoted content views

For each content view that you promote to a specific lifecycle environment, orcharhino creates a corresponding content view environment. orcharhino labels these environments using the format: <lifecycle_environment_label>/<content_view_label>.

Content view environment ordering and priority

The order of content view environments on a host or activation key determines which repository version the host uses when the same repository exists in multiple content view environments.

During host registration, an activation key assigns content view environments in the order in which they are stored.

A host pulls content from the first assigned content view environment that contains the repository. If Library is first in the list, it overrides other content view environments because it contains all repositories.

Content view environment order is critical when repository conflicts occur. A repository conflict occurs when multiple content view environments contain a repository with the same label. For example: A host assigned to the content view environments Library/cv1, dev/cv1 uses the following configuration:

$ hammer host update \
--content-view-environments "Library/cv1,dev/cv1" \
--name "server.example.com" \
--organization-id My_Organization_ID

Both content view environments include the orcharhino-client repository. Log in as a root user, then run subscription-manager repos to inspect the available repositories on the host. The output reflects the Library/cv1 content view environment:

$ subscription-manager repos

This results in the following output:

+----------------------------------------------------------+
    Available Repositories in /etc/yum.repos.d/redhat.repo
+----------------------------------------------------------+
Repo ID:   orcharhino-client
Repo Name: orcharhino Client
Repo URL:  https://orcharhino.example.com/pulp/content/My_Organization/Library/cv1/content/dist/layered/orcharhino-client/x86_64/My_Product/My_Repository_ID/os
Enabled:   0

The Repo URL reflects the Library/cv1 content view environment, meaning the system uses content from Library/cv1 and ignores dev/cv1.

To change priority, reorder the content view environments. To prioritize dev/cv1 over Library/cv1, update the host settings:

$ hammer host update \
--content-view-environments "dev/cv1,Library/cv1" \
--name "server.example.com" \
--organization-id My_Organization_ID

After reordering, inspecting the repositories again shows the dev/cv1 content view environment:

$ subscription-manager repos

This results in the following output:

+----------------------------------------------------------+
    Available Repositories in /etc/yum.repos.d/redhat.repo
+----------------------------------------------------------+
Repo ID:   orcharhino-client
Repo Name: orcharhino Client
Repo URL:  https://orcharhino.example.com/pulp/content/My_Organization/dev/cv1/content/dist/layered/orcharhino-client/x86_64/My_Product/My_Repository_ID/os
Enabled:   0

The Repo URL now reflects the dev/cv1 content view environment, meaning the system uses content from dev/cv1 and ignores Library/cv1.

Assigning content view environments to hosts in bulk

Assign content view environments to multiple hosts at once to provide the same content for those hosts.

Prerequisites
  • If you want to assign multiple content view environments, the Allow multiple content views setting must be enabled. For more information, see Content view environments overview.

Procedure
  1. In the orcharhino management UI, navigate to Hosts > All Hosts.

  2. Select the hosts to which you want to assign content view environments.

  3. Click the hosts table menu icon and select Manage content > Content view environments.

  4. Edit the content view environments as needed.

    • Click Remove to remove a content view environment.

    • Click Add content view environment to assign an additional content view environment.

    • Drag and drop the content view environments to change their order.

  5. Click Save.

Assigning content view environments to a host by using orcharhino management UI

Assign content view environments to a host to provide content access for that host.

Prerequisites
  • If you want to assign multiple content view environments, the Allow multiple content views setting must be enabled. For more information, see Content view environments overview.

Procedure
  1. In the orcharhino management UI, navigate to Hosts > All Hosts.

  2. Click the name of the host to which you want to assign content view environments.

  3. On the the Content view environments card, click Assign content view environments.

  4. Edit the content view environments as needed.

    • Click Remove to remove a content view environment.

    • Click Assign another content view environment to assign another content view environment.

    • Drag and drop the content view environments to change their order.

  5. Optional: Select Update the host immediately via remote execution to update the host immediately.

  6. Click Save.

Assigning content view environments to a host by using Hammer CLI

Assign content view environments to a host to provide content access for that host. Use Hammer CLI when you automate configuration.

To assign content view environments to a host, specify the entire list in order. There is no interface in Hammer or the API to add, remove, or insert individual content view environments. The current content view environments on the host are replaced with the new list you provide.

Prerequisites
  • If you want to assign multiple content view environments, the Allow multiple content views setting must be enabled. For more information, see Content view environments overview.

Procedure
  1. List available content view environments in your organization:

    $ hammer content-view-environment list --organization "My_Organization"

    Record the labels of the environments you want to assign to the host.

  2. Assign the content view environments to the host:

    $ hammer host update \
    --content-view-environments="Library/along_cv,LCE_XYZ/CV1" \
    --name "server.example.com" \
    --organization-id My_Organization_ID

Assigning content view environments to a host by using Subscription Manager

Assign content view environments to a host to provide content access for that host. Use Subscription Manager when you configure content access from the host rather than from orcharhino.

Prerequisites
  • If you want to assign multiple content view environments, the Allow multiple content views setting must be enabled in orcharhino. For more information, see Content view environments overview.

  • You have a orcharhino username and password, which Subscription Manager requires to list available environments.

Procedure
  1. List available content view environments:

    $ subscription-manager environments --list

    Record the names of the environments you want to assign to the host.

  2. Assign the content view environments to the host:

    $ subscription-manager environments --set My_Content_View_Environment_1,My_Content_View_Environment_2
Verification
  • List the assigned content view environments:

    $ subscription-manager environments --list-enabled

Comparison of content view environments and composite content views

Compare composite content views and content view environments to decide how hosts access content from more than one content view. The differences include access timing, conflict resolution, and version selection.

Composite content views provide an alternative method for granting hosts access to content from multiple content views. You can use composite content views, multiple content view environments, or a combination of both. The key differences between these methods include the following:

Access timing

Hosts assigned to composite content views gain access to the combined content only after you publish the composite content view. Hosts assigned to multiple content view environments immediately access the combined content from all assigned environments.

Conflict resolution

Composite content views resolve conflicts at the time of publishing by merging duplicate repositories. For hosts assigned to multiple content view environments, repository conflicts are resolved based on the order of content view environments.

Version selection

Composite content views allow you to select specific versions of a content view, including older versions. With multiple content view environments, the host receives the version of the content view that is currently promoted to the selected lifecycle environment.

Choose the approach that best suits your requirements based on these differences.

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").