Content Management Guide¶
Content management is a central feature of orcharhino. Within the context of orcharhino the term content management primarily refers to the provisioning of software beyond the basic operating system on some given host managed through orcharhino. For example, a host that is to be used as a web server would typically require access to any packages needed by the Apache server (or something equivalent).
orcharhino’s content management offers a highly flexible framework, that can be adapted to a wide variety of use cases. Many operating systems and content types are supported, as well as version control and lifecycle management.
As a result, orcharhino’s content management features several interrelated parts and a relatively high degree of conceptual complexity. This guide exists to break down that complexity, so as to provide an accessible introduction.
The content management guide contains the following subsections:
Refer to the content menu for more information on using orcharhino’s content management.
To make any progress in understanding orcharhino’s content management we must first introduce the key terminology involved. This subsection of the guide provides background information, and can also serve as a quick reference.
Repository: The smallest storage unit for software content in orcharhino. A orcharhino software repository generally needs to be synchronized with some content source outside of orcharhino to obtain content. To be usable in orcharhino, a remote repository must be of a type supported by orcharhino. These types are deb, yum, Puppet, Docker, and file.
Product: A named collection of one or more repositories. A single product may contain repositories of different types. Generally, repositories can only ever be added to orcharhino as part of some product.
Subscription: Within the context of Red Hat Enterprise Linux, subscriptions are used to limit how many times some given Red Hat product may be used (depending on how many Red Hat subscriptions were bought). For products not limited in this way, each product corresponds to exactly one unlimited subscription.
Red Hat Subscription: For Red Hat customers, orcharhino provides additional features for the management of Red Hat content.
SUSE Subscription: For SUSE customers, orcharhino provides additional features for the management of SUSE content.
Content View: A named and versioned collection of repositories. Whenever a new content view version is created (published), the current software content state of the repositories within it is frozen. Any subsequent changes to the underlying repositories will no longer affect the published content view version.
Composite Content View: A content view created by combining existing content views. Unless noted otherwise, we will use the term “content view” to refer to both content views and composite content views in this guide.
Lifecycle Environment: A lifecycle environment exists to restrict host access to content based on the hosts role or affiliation. For example, the classic scenario for lifecycle management is to distinguish between hosts for development, testing, and production. (In this scenario hosts would be assigned to either the development, testing, or production lifecycle environment). It would then be possible to run different versions of the same software in the different environments. This way, new versions of a software can be developed, and then tested before being used in the production environment, greatly reducing the risk of disruption by prematurely rolled out updates.
Lifecycle Environment Path: Lifecycle environments are organized into directional paths. Content view versions are then “promoted” through the path. Sticking with the previous example, a new content view version would be used in the development environment fist, then be promoted to testing, and only enter production once it has been sufficiently tested. It is possible to create multiple lifecycle environment paths, containing a variable number of lifecycle environments. All paths originate from the “library” environment, which is always present by default.
Activation Key: Part of the mechanism used for hosts to register with orcharhino’s content management. An activation key is associated with exactly one lifecycle environment and exactly one content view (though this may be a composite content view). An activation key must also be associated with one or more subscriptions (which generally correspond to products). When a host registers using a given key content is made available to the host. The content that is made available is the set theoretic intersection, between the content present in the key’s content view/lifecycle environment combination, and the content present in the key’s subscriptions. (See the below image for a visual representation).
Subscription Manager: The client-side software is responsible for registering hosts with orcharhino’s content management using an activation key, as well as managing the hosts repository access once registered.
Katello Agent: The client-side software allows orcharhino users to manage registered hosts (content hosts) within orcharhino’s management UI.
Content Host: A host which is managed through orcharhino’s content management. Each content host is always associated with exactly one content view and exactly one lifecycle environment.
The Katello agent supports package actions for Red Hat and SUSE based systems. The remote execution plugin additionally supports package actions for Debian and Ubuntu. As a result, use of the Katello agent for package actions may be deprecated in favour of the remote execution plugin in the not to distant future.
This subsection of the guide answers the question what one can do using orcharhino’s content management. The following list can also be read as a feature set:
Gaining access to SUSE and Red Hat Enterprise Linux content. (Only relevant to SUSE and Red Hat customers).
Adding content sources (repositories) to orcharhino (organized into products) and synchronizing orcharhino with those (remote) repositories.
Creating orcharhino content views (and/or composite content views) to create useful collections of repositories. (For example: All the repositories needed by a particular type of database server.)
Publishing content views for version control. This action will freeze the current state of all repositories in the content view, to create a stable software source (referred to as a version of the content view).
Creating lifecycle paths and lifecycle environments to restrict content access to a particular content view version based on role.
Promoting particular versions of content views through a lifecycle path (into the next lifecycle environment) to upgrade content in a careful and controlled way.
Creating activation keys to register hosts (or entire host groups) to a particular content view and lifecycle environment (further restricted using subscriptions).
Refer to the setup subsection for more information on how to do the above things.
Supported Content Types¶
These content types are related to the various repository types supported by orcharhino. However, a repository of a given type, might contain content of several different types. For example, repositories of type yum may contain content of type errata, as well as content of type RPM package. Repository types include deb, yum, Puppet, Docker, and file.
When confronted by the various menu items in the content menu it is not immediately clear where to begin. However, the relations between the various parts of orcharhino’s content management do imply a logical order. For example, it makes little sense to create content views before importing the relevant content (in the form of products).
This subsection of the guide introduces a natural order in which to approach orcharhino’s content management, providing a kind of step-by-step setup guide. It should be of particular interest to first time users and orcharhino administrators.
Before you actually start creating the various content management entities, you may also want to check the strategy and best practices subsection.
To avoid duplicate documentation, we will make frequent references to the relevant subsections from the content menu section of the management UI chapter. Follow these references for detailed documentation on how to perform each step described.
SUSE and Red Hat Enterprise Linux Content¶
This subsubsection includes step-by-step instructions on how to add SUSE and/or Red Hat Enterprise Linux (RHEL) content to orcharhino. If you are neither a SUSE, nor a RHEL customer, skip this section (continue with products, repositories, and synchronization).
For RHEL customers:
Import a Red Hat manifest file (can be obtained from Red Hat). Once you have imported your manifest file, any associated Red Hat content will automatically appear on the Red Hat repositories page.
Select Red Hat content for inclusion in orcharhino. Once RHEL content has been selected, it will automatically appear in the form of orcharhino products.
Synchronize your new Red Hat products (continue with products, repositories, and synchronization below).
For SUSE customers:
Add your SUSE Customer Centre (SCC) accounts to orcharhino. Any number of SCC accounts can be added to orcharhino. Once a SCC account has been added (and synced) any associated SUSE products can be selected for inclusion in orcharhino.
Select SUSE content for inclusion in orcharhino. Once SUSE content has been selected, it will automatically appear in the form of orcharhino products.
Synchronize your new SUSE products (continue with products, repositories, and synchronization below).
Products, Repositories, and Synchronization¶
This subsubsection includes step-by-step instructions on how to add arbitrary content to the orcharhino server. If you are a SUSE or RHEL customer and followed the steps for SUSE and Red Hat Enterprise Linux content above, you will already have some products within orcharhino. In addition, it is possible to add your own products with your own private or publicly available repositories (for example via a link to a public mirror):
(Optional) Add GPG keys and/or SSL certificates to orcharhino.
(Optional) Create any sync plans you may want for your products.
Create and synchronize any desired products (with repositories).
Create the empty product.
Add any desired (remote) repositories to your product.
Manually synchronize your new product, or wait for your sync plan to take effect.
(Optional) Check on the synchronization status of your products.
Depending on your download policy (set for individual repositories), synchronization will create a local copy (on the orcharhino server) of all repositories contained in each product being synchronized. Depending on the size of the repositories involved, and the speed of the internet connection to them, this can take a significant amount of time. Many hours are not uncommon and should be planned for accordingly.
Once your products are synchronized, continue with content views and lifecycle environments/paths.
Content Views and Lifecycle Environments/Paths¶
This subsubsection includes step-by-step instructions on how to manage content on the orcharhino server once it has been successfully synchronized. These steps are necessary to provide version control and lifecycle management for this content.
(Optional, best practice) Create any lifecycle environment paths as desired.
Create new environment paths by appending a single new lifecycle environment to library.
Complete your new environment paths, by appending additional new lifecycle environments to the ends of existing paths.
Create any desired content views.
Create the empty content view.
Add any desired (local) repositories to your content view.
Publish a new version of your new content view (version 1.0)
(In the future) Publish additional major versions of the content view once the underlying repositories have changed (2.0, 3.0, etc.) or
(Optional) Apply errata to a major version of the content view to create minor versions (like 1.1, 1.2, 2.1, etc.)
Promote relevant versions of your content view through your lifecycle environment paths. (Different versions can be assigned to different environments in a path).
(Optional) Create any desired composite content views.
Create the empty composite content view.
Add any desired (existing) content views to your composite content view.
Select which version of the added content views should be used.
Publish a new version of your new composite content view (version 1.0)
(In the future) Publish additional major versions (2.0, 3.0, etc.) of the composite content view once additional content views have been added or if new versions of the underlying content views should be used.
Promote relevant versions of your content view through your lifecycle environment paths. (Different versions can be assigned to different environments in a path).
Once content views and lifecycle environment paths have been fully created, continue with the following subsection.
Activation Keys and Content Hosts¶
This subsubsection includes step-by-step instructions on how to register content hosts with orcharhino (using activation keys). Provisioning content hosts with content managed through orcharhino is the ultimate goal of orcharhino’s content management.
Create any desired activation keys.
Create the key using exactly one lifecycle environment and exactly one content view (or composite content view)
Add any desired subscriptions to the key.
(Optional, discouraged) override repository sets as desired.
(Optional) Add any desired host collections.
(Optional) associate your host groups with new activation keys as desired.
Create any desired content hosts. Content hosts are created by registering an existing (plain) host with orcharhino’s content management (using an activation key), or by creating new hosts belonging to a host group already associated with some activation key.
Once content hosts have been successfully created, they can be managed through orcharhino.
This subsection of the content management guide includes instructions on how to make effective use of orcharhino’s content management after it has been set up. As such, this subsection presumes the presence of fully entitled content hosts with access to fully configured content views, lifecycle environments, and subscriptions. Refer to the setup subsection if you do not yet have these things set up.
Strategy and Best Practices¶
This subsubsection provides some examples and best practice guidelines for how orcharhino’s content management could be used. Note that these examples may not be suitable for all use cases and should be viewed as friendly suggestions.
We recommend keeping products as small as possible. For example, one product each for
PostgreSQL-8.1with one repository each is better than a single
PostgreSQLproduct including multiple repositories for different versions. Likewise, we recommend separate products for things like
PostgreSQL 7.1rather than a single
WebServerproduct. Since products correspond to subscriptions, small products will give you greater control over what subscriptions (and by extension what content) is used (via your activation keys).
There are two basic approaches to content views: Either create content views that contain everything needed for a certain type of host, e.g. a
WebServercontent view, which includes repositories for
PostgreSQL-7.1. Alternatively, create a content view each for
PostgreSQL-7.1along with a composite content view
WebServer, which includes all of these content views.
The same two basic approaches exist for activation keys: Either create a single activation key for a specific kind of use case (e.g.
corporate_webserver_prod), which uses the
WebServercontent view and selects all subscriptions necessary to run the service. Alternatively, create separate activation keys like
database_mysql_prod, all using the same content view (i.e.
WebServer) along with a different set of subscriptions.
Information relevant to errata management is available in various locations in orcharhino’s management UI. This subsubsection exists to collect the entire workflow relevant for errata management in a single place. As such, it is meant to complement the relevant documentation elsewhere in this document, and will make frequent references.
When dealing with errata, care must be taken to distinguish between applicable and installable errata. An erratum is applicable to a content host if that host has packages affected by an issue that the erratum fixes. An erratum is installable if it is both applicable as well as present in the relevant content view version, such that the relevant content host has access to it.
The expected workflow for obtaining and applying errata goes as follows:
Any content hosts with any applicable errata (see the info box above) will now display a relevant warning on both the all hosts page as well as their individual host overview page. Note that the content hosts page as well as any content host overview pages list only installable but not applicable errata.
Once alerted to the presence of applicable errata, the orcharhino user can review new errata and select them for application on the errata page.
To help choose which errata to select for application, each erratum has a detailed description as well as a list of affected packages on the relevant erratum overview page.
Detailed documentation on applying any chosen errata can be found in the applying errata section of the errata page. This process generally involves publishing a new minor content view version to ensure any merely applicable errata also become installable.
Once the desired errata are installable, they can be installed via remote execution, or directly on the host in question. There is a checkbox to do so as part of the previous step.