Foreman content plugin design [doc-version 0.0.1]

Development
1

Hi,
This is a request for comments on an effort to build a content management plugin for foreman.
The content plugin goal is to enable software repositories management and assignment to hosts within foreman.
In the future it should also manage the synchronization of the software repositories to different locations,
manage puppet module versions and distribution to puppet masters.

The design work is partly based on ideas and definitions from [1]
The foreman content plugin uses pulp project [2] to manage the software repositories, currently pulp is only
managing yum repositories and puppet modules, a work to support debian repositories in pulp is in progress.

[doc-version 0.0.1]

  1. Reasoning

When managing host classification with foreman, It makes sense to manage not only the puppet modules
and parameters assigned to each host but also the software repositories the host consumes.
Managing software repositories with the corresponding puppet modules, enable a cohesive host configuration
and provisioning results.

  1. Design

2.1. Goals

  • To enable building and maintaining a standard operation environment.
  • To provide a way to control the content available to each host and hostgroup across the entire organization.
  • To provide a mechanism to control release process that supports maintenance windows and enable rolling upgrades.
  • To enable provision a machine to a specific point in time.

2.2. Concepts

Entities:

··· --------- Product - A group of repository definitions that represent a logical product. Repository definition - A feed url and filter rules Filter rule - A single rule designed to filter packages or errata. Can be a whitelist rule or blacklist rule. Operating system content - A group of repository definitions,just like product, with the exception that a host can be installed from one of the repositories.

Content view - An immutable, point in time, collection or repositories.
Product content view - each product can have multiple content views, each content view represent a version of the product.
Operating system content view - each operating system can have multiple content views, representing the patch level at the time of creation.

Creating a content view of a product or an operating system creates a clone or a set of clone repositories.

Relations with existing foreman objects and actions:

A host should be able to consume content from a number of content views, the operating system content view, the
hostgroup content views (can be multiple, one for each product) or host directly attached products-content views.

A hostgroup can have a collection of products.
A content view can be available in one or more environments.
Only one content view can be the product-environment default.
A content view can be archived in an environment, an archived content view will not be available for hosts.

Actions:

Sync - get upstream updates for a repository or a group of repositories.
Publish - create a content view for a product or an operating system.
Promote - enable a content view in an environment.

2.3. Workflows
Creating an os content view for CentOs 6.4

  1. Create a new repository select repository type os-kickstart, select os CentOs 6.4, add the kickstart repository.
  2. repeat the step above with os-yum repository type and add the updates repository.
  3. repeat the step above and add any additional repository needed for your standard operating environment.
  4. On operating systems, publish (create content view) to an environment or a set of environments.

Creating a product content view for My-Product

  1. Create a new product and give it a name, select (multiple options) the availability in operating systems.
  2. Create a repository for each architecture.
  3. In products select, publish to the relevant environments.

Add content to Hostgroup

  1. in Hostgroup content tab, select a list of products.

Promote operating system update

  1. Sync an operating system repositories.
  2. Select a base the content view.
  3. Select the erratas and package updates you want and publish (create a new content view) to environments, could be a test environment.
  4. Create a host with the new content view, when happy with the results set the content view environment availability, could be production environment.

Provision a new host

  1. Create a new host, in the new host form select hostgroup and environment.
  2. In the operating system tab, in installation media, you can select a content view or have the operating system default content view.
  3. In the content tab, a list of products inherited from the hostgroup will be displayed,
    additional products may be available depending on operating system and environment.
  4. For each product select a specific content view or keep the product default content view.

Rolling upgrade for a product

  1. Once a new product update content view is available in an environment, select a group of hosts.
  2. In the bulk operation drop down select change content view, and select the product and content view.
  3. If the service performs well repeat step 2 with a new group of hosts.

Create content view based on a filter

  1. To select part of the packages of an upstream repository based on filters,
    create a repository, select product and set the feed url, in the filters tab add filters.
    A filter can be black or white list, it can be erratas type or severity, etc.

  2. Publish the products, the resulting content view should be a filtered view or the repository.

  3. Current state of the plugin
    An initial prototype has been released [3], the current prototype doesn’t support content views and filters.
    It does however possible to clone upstream repositories, kickstart hosts using the repositories, and set the host yum repositories with puppet.

Amos.

[1] https://fedorahosted.org/katello/wiki/ContentViews
[2] http://www.pulpproject.org/
[3] https://github.com/theforeman/foreman_content