Steven, Whilst I'm not a Satellite guru, it should be considered merely as repo only. Satellite as far as I am aware does not pro-actively visit any boxes and perform maintenance on them. It does provide the opportunity for boxes to update themselves.
I'd be interested to hear other people's experiences here, but I would suspect that you should not allow any of your machines to subscribe to the default RH channels, but create your own, which you have control over, and can update when you are ready through you own dev-tes-UAT-prod. The question of whether you should use ensure => present vs "latest" in this set up is definitely one I'd like to see people's views on in this situation. If you do have suitable testing in place, there shouldn't be any reason why ensure latest would not be the way to go. However, as you scale, the Puppet runs may take a while checking to make sure they are up to date. Puppet 3 has reduced a lot of latency, so maybe this option is a bit more acceptable these days? I'll continue watching this thread to see what other people are up to. Stephen On Thursday, 5 September 2013 13:02:40 UTC+10, Steven James wrote: > > Hi, > > A little off topic perhaps, but thought somebody may have some insights > with the following. I'm trying to anticipate and plan for any contests > between Puppet and RHN Satellite. > > The thought to try and get them to play together may be as follows; > > Satellite will.... > 1) Provision a base RH server. > 2) Patch and maintain the base server's components. kernel, etc. > 3) Install the RHN and Puppet agents. > 4) Have a test, qa and prod RH channel set up. > > Puppet will... > 1) Promise to play nicely :) > 2) Configure the yum repos on the clients to point to either test, qa or > prod channels > 3) Build and assure the state of wonderful (non-base server) packages, > config files and make sure that all of the services are configured. > 4) See that all of its modules are set to (package) ensure => latest > > So we've got to the end of day one, and all is well. > > *Plus one week...* > > We have a kernel update, and Mysql have released a patch. How do we get > them onto the boxes, and progress this through the environments? > > 1a) Satellite will update the test channel, with the new kernel patch. > 1b) Satellite will patch all servers that subscribe to the test channel > > * Puppet remains happy, so long as we do not have any dependencies on > kernel revisions > > 2) Puppet "sees" (via ensure latest), that there's a new version of mysql > in the test yum repo, which it will faithfully apply, pulling down any > additional supporting packages from the test yum repo and libraries as > required. > * Satellite is happy as Puppet has not changed any of the files that it > is responsible for. > > 3) We run some tests against the servers in the test env to make sure > there is no smoke > > 4) We freeze the sat test channel, and rsync to the QA channel. The > goodness flows from there. > > Does this approach sound scalable, sensible and workable? > > Can we tell Satellite that it is only responsible for the base server > packages? i,.e. should web configure maybe 3 new channels, called > test_base, qa_base and prod_base for example. These would be the only > channels that servers would ever subscribe to. Maybe a "base server build" > is actually too big, and we should be telling Satellite to only manage the > absolutely min number if files to get the box booting. A list of 2-300 > packages I would imagine. If this does sound appropriate....does anybody > know where i might get this list? Maybe it's a Satellite supplied template > for a channel? (not holding my breath on that one.....) > > My interest just now is purely around how to get Puppet and Satellite > playing nicely together. The commitment and decisions for Satellite have > already been made. I know that there's a whole new other workflow around > progressing Puppet changes thru the environments ;) > > I'd really appreciate any insights anybody has around this stuff. Happy to > share experiences over the next week or two. > > Regards, > > Steven > > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
