Satellite 6.1.x - Real world errata management
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.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
