Trying to grasp Content Views and Life Cycle environments
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?
Responses
Hello, these concepts are covered in this presentation:
Migrating an existing Puppet deployment into Red Hat Satellite 6 - YouTube - https://www.youtube.com/watch?v=04m6SlvzvKY
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 - https://access.redhat.com/articles/1585273
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).
Example:
- 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:
- For errata, use the Incremental Updates feature as described in Satellite 6.1 Feature Overview: Errata Management
- For package updates, use the
hammer content-view version incremental-updatecommand with the--packagesoption.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
