Host patching based on Environment (PROD vs DEV, etc...)

Latest response

I realize this is covered by the docs and tips and tricks from Summit.  I am still curious how others are going about managing their own host deployments and management.  I feel as though I am missing a key aspect of how Satellite was intended to be used.

We have multiple environments – PROD and DEV.


Let's say that we want to roll our DEV hosts to a point in time (2013-02-01) and validate them at that point. Once validation is complete we would like to roll our PROD hosts to the same point.


We have

rhel-x86_64-server-6 (ALL)

-- jbappplatform-5-x86_64-server-6-rpm (1 of 3)

-- rhel-x86_64-server-optional-6 (2 of 3)

-- Dell-OMSA (2 of 3)

-- rhn-tools-rhel-x86_64-server-6 (ALL)

So – would clone the base channel and all the children (via CLI)? And then literally resubscribe the systems from one release point to another? If so, how do I easily make sure that the children channels they were subscribed to are retained? I.e. So that when I am done only the 1 system is subscribed to the Jboss channel, 2 systems are subscribed to rhel server optional, 2 subscribed to the Dell channel and all of them still have rhn-tools-rhel-x86.

What are my other options? I do not like the idea of changing the subscriptions based if they won't retain their original base-to-child relationships. Unfortunately I only have the one Satellite to test with and I don't want to blow the poor thing apart ;-)

On a possibly related note: do people find value in the spacewalk-clone-by-date command? 



There's another post in the group here ( that lays out a basic structure on cloning.

Create a series of clones based on your flow, e.g. RHN->dev->test->prod.

Use clone-by-date to manage updating the errata from RHN base channels to dev.  Test these updates here, add or remove whatever errata need to be changed, then promote the content from dev to test with clone-by-date again.  Rinse, repeat.  No need to change the base channels on systems unless your systems are actually moving from one environment to the next.

With lots of channels, you may want to set up a config file (see the other thread for an example) to deal with each transition, e.g. RHN-> dev, dev->test, etc.

There is also a script out there in the spacewalk-utils called spacewalk-manage-lifecycle that will do the creation and promotion for you, but I've noticed (and am trying to work on) a bug in the logic for channel names that happens during promoting child channels.

Thanks Matthew!  With this information I was able to craft an implementation that I think will fit well with my requirements.