Trying to grasp Content Views and Life Cycle environments

Latest response

I thought I finally got how content views and life cycle environments work but I'm not able to grasp how to get a single in-house package promoted. I'm starting to think I need to redo my Environment.

My environment path is

'Library' with 3 Environments, Dev, Test and Prod.

For the sake of simplicity I have 1 content view for each version of Red Hat we are supporting.
My Content view "RHEL7 All" contains the RHEL7 Products I need plus "EPEL", and a "Custom" repo where our in house packages are placed.

The work flow is as follows:

  • 2nd Tuesday of month I Publish a new version (Version 4.0 for example) and Promote to Dev. The content is everything - about 36600 packages, 5400 Errata. No filters used.
  • 3rd Tuesday of the month I promote to Test
  • 4th Tuesday of the month I promote to Prod.

New month I repeat, creating a version 5.0

Now I want to make an rpm available to all environments which is uploaded to the Custom Repo, without promoting anything else such as errata or other packages. Do I use a filter within the 'RHEL7 All' Content view for just the one package and promote it through to production, then Delete the filter when done?


I figured out that it is best to separate my content views to smaller groups and use composite content views. I can promote one content view then update the version in the composite content view which I can then promote.

Composite content views are more manageable in my opinion. Promoting content is also quicker.

Hello, these concepts are covered in this presentation:

Migrating an existing Puppet deployment into Red Hat Satellite 6 - YouTube -

This is also worth reading: 2015 - 10 Steps to Build an SOE: How Red Hat Satellite 6 Supports Setting up a Standard Operating Environment - Red Hat Customer Portal -

At its core, a Content View is 'a collection of repositories that are on the same lifeycle'. From a design perspective you generally keep repos which have dependencies on each other grouped together. Example: RHEL 7 Server, RHEL 7 Server (Optional), and Satellite-tools should almost always be in the same content view.

For your usage, I would suggest using content view filters. When you republish a new version without filters, you get the state of the repositories as they exist in the Library (which is as current as your last sync). This is the behavior you are seeing when creating v. 5.0 of your content view. Implicit release of content, IMHO, is bad.

I'd suggest doing the following. Add two filters to your content view:

  • An include Filter of type Packages and select the 'include packages with no errata' option. This filter allows you to include both Red Hat packages without errata (such as those when a repo is first released, kickstart repos) AND your custom packages
  • An Include Filter of type 'errata by date/type', and set an end date of your choosing and optionally include only security, bugfix, and/or enhancement errata. This allows you to limit which errata are released.

A few notes:

  • Note: with include filters, anything not explicitly included is removed. With the above filters you will get exactly the errata or package you defined (and no more).
  • Note 2: exclude filters are processed AFTER includes.
  • Note 3:. If you want, you can be really explicit and use include filters on your custom repos to only include specific packages from that repo. But that is not strictly needed.
  • Note 4: Filters can be set globally on a content view or scoped to a individual repository.
  • Note 5: Filters allow you to more easily build a patching methodology (since you can 'loosen' the filters as needed)
  • Note 6: If you choose to use filters AND you are using Capsules, you MUST include the kickstart repo in your content view AND the first include filter above.
  • Note 7:: This Note is intentionally left blank. :)
  • Note 8: Filters let you more easily introspect what is actually in the content view.

The last thing you need to worry about is if you need to roll out a new package outside of your normal patch window/release cadence. Over time, you are definitely going to have differing versions of content views in each of your environments (Dev, Test, Prod).


  • v. 7.0 is in Dev
  • v. 4.0 is in Test
  • v. 2.0 is in Prod.

What happens if (or more precisely when) the next Shellshock comes out? Or what if you want to want to push a single package to ALL the environments (and make no further changes) ? You can create minor versions 7.1, 4.1 & 2.1 of those content views:

I would change

FROM: Example: RHEL 7 Server, RHEL 7 Server (Optional), and Satellite-tools should almost always be in the same content view.

TO: Example: rhel_base_os_7_cv ( RHEL 7 Server, RHEL 7 Server (Optional)) should almost always be in the same content view. Sat_Tools_63_cv should be in it own content view . A composite content view such as rhel7_compo_cv (would have rhel_base_os_7_cv and Sat_Tools_63_cv )

So when Sat_Tools_64_cv comes out , it is easy to deploy that across the whole env.

Why should Sat Tools be in a separate content view?

Due to version changes , aka if I want to go back in time , aka back to sat 6.2 days , or cleanly removed satTools_6_minor from the env , aka sat62_tools , etc.

Sat 6.2 was ga around 7/2016 , so if I have a need to go back in time for my machines content it is easy to retro fit old patch train with the composite views , the new patch train of satTool64, satTools65, etc content.

  • aka rhel7_compo_cv copy this back to 16Q2_rhel7_compo_cv, find the cv from 16Q2 version , and add the new Sat_Tools_64_cv , so ever thing works .

    • Aka latest sattools and old version of all the other stuff need for some BU (businesses unit). My guess is the vmware tools may need to be latest greatest but I am not a SME on vmware tooling.
  • IMHO As I think this is the cleanest way to remove old channels , as least painful way to remove sat62 repos due to the db lock / ?

  • IMHO it is easier to look for the cv for Sat_Tools_62_cv, Sat_Tools_63_cv and remove that cv from my env, once I know that cv is gone I can remove the repo and get that space back , but same pattern for vmware_tools etc.
  • As pure CV are a gold mine for DB versioning , 6 to 24 month down the line , to get back to that state as close as you can , you might as well use the product as it was intended

Ahh! Makes sense. Thanks for the reply!

As we are on a 6 month patching train for sat or , that is what Rich says. You will need to do this #2 time a year. * aka 2019 March/May , Oct/Nov

I was having some trouble setting filters in a CV with RHEL+EPEL repos.

Then I found out about KCS 1451913 and Bug 1624199.

How can I structure a CV/CCV with EPEL and filters?

I suppose I could:

  • create cv_rhel7 with official rhel7 repos
    • setup filters like described above
  • create cv_epel7
    • create only exclude filters;
  • ccv_rhel7 = cv_rhel7 + cv_epel7 (composite)

I was trying to keep away from composite views, but it seems to be impossible if you want to use filters and EPEL or other 3rd party repos.

Looks like i've come to the same conclusion, EPEL seems to give random numbers of packages in each promotion when used in a filtered content view and jumping around with filters breaks stable rhel snapshots, also have some other 3rd party content that doesn't come through properly.

Is this content from Rich published in any other documentation?

How does this work now with RHEL 8 and content streams

It should work the same way.

RHEL8 repositories are like RHEL7 ones with modularity metadata, that can (dis)allow access to specific versions of some packages. Content Views by default cary forward the modularity info, as well as you can apply filters based on modularity, if needed. (anyway if you plan CV filters with modularity, I suggest testing the final content first - I recall there are/were some issues with correctness of the CV filtering).