2 phased patch roll-out and need to restrict phase 2 patches to mirror earlier phase 1 patching
I am running Satellite 5.8. We have a need to roll out patches on the Test servers 10 days before pushing them to production.
I am trying to find a way to lock in the patches that will get pushed to production to be the same as the ones that were installed on the Test boxes.
My concern is that in the time between the Phase 1 (Test) and the Phase 2 (Prod) roll-out some new patches/errata could be released. I don't want to include those in the Production patching.
Is there any way to "approve" patches for installation or to lock in a set of patches for future installation?
Responses
John,
This is a common requirement.
My suggestion is, if they are both subscribed to the same parent channel, copy/clone the packages and errata into a child channel which represents the patches you want to implement as part of this patch release.
Subscribe all your Test (Phase 1) servers to this patch child channel and update them.
After testing/configuration, subscribe the Prod servers to the same patch child channel and patch them
It's critical when using this process that the base channel doesn't receive any updates. If your configuration is such that the base/parent channel is receiving updates, you should clone this base channel and move the servers over the to the clone to maintain the baseline (then implement the child channel as described above)
I didn't develop the tool, I am providing a process in the UI to implement the outcome you requested.
This is in essence an approval process as you are making the patches available to the downstream clients. Clone errata into child channels or cloning base channels is a common approach in Satellite 5.
If you don't take this precaution, any users on the servers can apply the patches as they are 'available' or 'approved' in the channel. Additionally, if you are building/patching new servers between the phases (ie. building new prod servers) they will build to the 'test' patch level if you haven't restricted the errata in this way.
Here is the documentation on the exact subject from Red Hat's Rich Jerrido
red_hat_satellite-5.6-satellite_errata_management-en-us.pdf
This approach doesn't required modification of channel subscriptions as each 'class' of server is subscribed to it's own channel and the channel is then updated with errata.
Please let us know how you solve it.
All,
I would not create a child channel.
I would clone the base channel first using spacewalk-clone-by-date. Then clone the child channels as the children of the cloned base channel.
Then subscribe all servers to bundle of cloned channels.
Each time you wish to update the servers, just rerun the clone steps.
Als take a look at: spacewalk-manage-channel-lifecycle
Regards,
Jan Gerrit
Jan,
"I would not create the child channels". Your solution creates child channels as clones? What are these child channels cloned from? "Then clone the child channels as the children of the cloned base channel."
My approach is as follows (described above):
- Create clone of base channel (to ensure baseline doesn't move) and move all servers to this base channel (ie. this can be your 'template' repository for new builds), or clone the media base channel.
+ Clone of RHEL 7.4 media channel
- Create child channel that includes the errata that you want to release to the servers as part of the patch release
+ Clone of RHEL 7.4 media channel
+--- Errata bundle 1
To 'release' or 'approve' errata to the Test systems, subscribe all the Test (Phase 1) servers to the 'Errata bundle 1' child channel and patch
Update Test (Phase 1) activation key to include 'Errata bundle 1' so new 'Test' builds are created at the same patch level
When testing is complete, subscribe all the Prod (Phase 2) servers to the 'Errata bundle 1' child channel and patch
Update Prod (Phase 2) activation key to include 'Errata bundle 1' so new 'Prod' builds are created at the same patch level
To 'release' or approve a second bundle of patches a second bundle child channel can be created with either additional errata or a cumulative collection of errata to that date (so earlier child channels can be removed when systems are moved to the newer child channel).
An alternate approach is to just use base channels and clone by date (or channel clone in the UI) the entire channel, not just errata . This has the benefit of not tripping over incorrect dependencies in rpms which is discussed in another current thread.
- Clone base channel from 'latest' upstream to new base channel and call it 'Patch Level 1'
- Subscribe 'Test' systems to 'Patch Level 1' base channel and patch
- Update 'Test' activation key to use 'Patch Level 1' base channel for new builds
- Subscribe 'Prod' systems to 'Patch Level 2' base channel and patch
- Update 'Prod' activation key to use 'Patch Level 1' base channel for new builds
Once this round of patching is complete, you can then follow the same process to create a new 'Patch Level 2' base channel using a base channel clone off 'latest' and then move the Test servers / Prod servers to this new base channel in a phased approach. Once patching of Prod is complete, the 'Patch Level 1' base channel can be removed as it should no longer have any systems subscribed. This approach ensures you don't get a build up of channels over time.
The reason for the restrictions I have described is to also account for the build of new servers during the patching cycle.
If you build a new server during this patch release phase, how are you managing what level of patches it receives as it won't be on your schedule? (I understand this may not be a concern in your environment).
Pixeldrift.net
We do not use the base channel from media, but the base channel as it is synced each night from CDN.
So it is "updated" with the latest errata on a daily bases.
With spacewalk-clone-by-date I first clone the base channel e.g. rhel-server-7 to clone-rhel-server-7
After this clone is complete including errata up to the chosen date, I will clone e.g rhn-tools-rhel-7 to
clone-rhn-tools-rhel-7-server as a child of clone-rhel-server-7. Repeating the last for each child channel I need for my
"service pack"
Regards,
Jan Gerrit
Then for the second patch release/cycle you repeat the process creating a new base channel with child channels and move everything over to this channel with the same phased approach?
This sounds the same as this method (although I haven't detailed the method of cloning associated child channels)
Clone base channel from 'latest' upstream to new base channel and call it 'Patch Level 1'
Subscribe 'Test' systems to 'Patch Level 1' base channel and patch
Update 'Test' activation key to use 'Patch Level 1' base channel for new builds
Subscribe 'Prod' systems to 'Patch Level 2' base channel and patch
Update 'Prod' activation key to use 'Patch Level 1' base channel for new builds
You could potentially include the rhn-tools repository in the channel you are cloning from to avoid the creation of a child channel :)
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
