Hi There,
Looking at your module approach, I think you are heading for quite a bit of 
pain, I've found that packaging tools such as RPM are best for this kind of 
task.

In my environment which is all RHEL based I (roughly) do the following:
- I have a number of YUM repositories defined and presented to the network 
via HTTP
- By default, all nodes have the standard production baseline YUM 
repositories enabled by default
- I use top scope variables to enable additional YUM repositories that may 
contain later package versions or testing packages via the yumrepo type
- Once these additional repositories are enabled, I can then use yum update 
to bring hosts up to a specific baseline of the OS or software set.
- Once I am happy with the functionality of this new repo, I can either 
promote it to be the production baseline or something similar.

Here is some puppet logic that operates on the $::enable_testing_repos 
value, and enables the testing repo if it is true for a host, else it is 
left defined, but disabled.

                   yumrepo { $rhelsysupporttestingrepo :
                        baseurl  => $rhelsysupporttestingrepourl,
                        descr    => "TESTING System support packages",
                        gpgcheck => '1',
                        enabled  => $::enable_testing_repos ?   {
                                        'true'  =>  '1',
                                        default =>  '0',
                                    }
                    }



Re: Spacewalk - I've just moved my entire fleet from spacewalk / satellite 
to YUM via HTTP (Apache) with repos created with createrepo, etc and find 
it much faster and flexible.

Hope this is of some use.

Thanks,

K






On Friday, November 9, 2012 4:04:44 PM UTC, Christian wrote:
>
> I have some questions in terms of how to use puppet of configuration 
> management for software patches. My previous approach was it to create a 
> puppet module for each patch ... Like Patch1 includes (FileA, FileB, 
> FileC), Patch2 includes (FileD, FileE)... So far so good and that works but 
> now i have to create a Patch3 with lets say FileF and FileA included. As 
> you can see there will be a puppet conflict as i can't deploy the same 
> files within different modules. What is the right architecture and method 
> to manage software patches? Is it to use rpms instead of? Or are there 
> other ideas how to manage that with puppet.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/vgJKdu76_VcJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Reply via email to