Satellite 6.1.x - Real world errata management

Latest response

I have a scenario (that I don't believe is unsuaul/atypical) that I worked through for a client and I am interested in seeing how others (particularly Red Hatters) would solve it. I was planning to write up / sanitise the content I have written so I could post it on the forums, because it's what I believe to be a fairly straightforward patching process (and it is in Satellite 5) that becomes unnecessarily convoluted when converted to Satellite 6.

Constraints/requirements:

1. The client has three environments
   - development
   - test
   - production

2. There are multiple projects that have errata applied at their own cadence, but all exist within these environments (ie. each project has dev/test/prod). Each project has it's own servers/infrastructure.
   - project_one
   - project_two
   - project_three

3. When the servers are deployed they receive all outstanding errata up to the deployment date (for the sake of this discussion, assume that all projects have the same starting date). After this point, they receive monthly errata rollups of security errata only which are created at the end of each calendar month. Errata must progress through each environment (dev/test/prod) for each project independently (ie. can't be applied to all 'dev' impacting all three projects).

4. Servers themselves do not move through environments. If a server is deployed/built as a development server, it will always be a development server. Likewise for test and production servers.

On face value this looks to be extremely straightforward to implement using content views, composite content views and lifecycles. I have solved it (in multiple ways), but as I mention above, all solutions seem convoluted.. so I am keen to see the 'Red Hat' way to solve a real world problem with the product.

I am happy to post the working solution (in Satellite 5 and 6) if others are concerned I am chasing free consulting time :)

Responses

I actually hopped on here to post this same question because my requirements are very similar.

I'm still experimenting with workflows on test nodes but I'd be interested to hear which convoluted solutions you've tried yourself.

Have you taken a look at 10 Steps to an SOE , specifically Step 4 (pgs 102-120). WIth regards to the 'Red Hat way' , that document covers the pros/cons of the various methods on how you can setup your CVs/CCVs/environments, etc.

The reality is that there is not one true way, as each org is different.

Thanks for posting this document link Richard, I hadn't come across it previous to you posting. I think this document has an excellent level of detail and supplements the other 'generic' Satellite documentation well.

Unfortunately, the document is essentially a validation of all the limitations I have found when implementing workflows in Satellite 6. Lifecycles is a good example, in Satellite 6, my listed scenario required 9 unique lifecycle environments to be created (on three lifecycle environment paths) because the lifecycle paths aren't namespaced. For each additional project that is added, three additional lifecycle environments need to be created (dev/test/prod). In Satellite 5, this process was handled well with separate groups for projects, and environments, which could then be combined with the 'Work With Intersection' to refine the host selection. In Satellite 5, each additional project only generated a single additional group.

The limitations I hit with content views, composite content views and the various workarounds are also well covered in this document. The note on page 118 (EPEL/Nagios example) summarises the kind of problems you hit when attempting to define core content, and then reference content out of the same repository in other places (which I raised in the Bugs/Issues threads).

The fact the document reiterates multiple times that a strict/complex naming standard needs to be defined for CVs (a conclusion I also reached) confirms the limitation in the CV structure and the information CVs provide to the end user. Because of this lack of information/visibility inherent in the structure, all the information needs to be encoded by the end user into the CV description free text field.

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.