On Tue, Dec 20, 2011 at 11:49 AM, Swampcritter <[email protected]> wrote: > We are developing in-house RHEL VM provisioning (similar to Satellite/ > Spacewalk) along with a customized kickstart template, but also > including Puppet to handle the actual configuration of the > environment. One thing we need to see is does Puppet have a variable > that will deploy one module only once and not check against it just in > case the configuration file it has created has been altered or not and > try to revert back.
I'm looking at a similar use for Puppet. We want to use Puppet to both provision and manage hosts. The provisioning process will set up a bunch of files according to our security / policy requirements, but not all of these files need to be controlled by Puppet for the life of the server. To put it another way, the number of classes used to manage servers will be a subset of the classes used to provision those servers. > The last part is the deciding factor -- as this part of the > requirements are quite possibly going to change via the developers > that are actually using the environment for testing and tweaking the > RHEL OS memory and TCP communication needs (/etc/sysctl.conf) or the > Apache /etc/httpd/httpd.conf code. We don't want Puppet to revert back > the code variables as these are being modified by hand and not using > SVN or any other type of code version control at this time. > > Anyone know if module exclusion is possible for a "deploy once, don't > touch again" scenario? I'm contemplating options for this. One is to use environments. In my scenario, I think I'd have two defined environments (provisioning and production), but configure both environments to use the same modulepath. This will allow us to reuse classes between provisioning and production. The provisioning environment would have a site.pp with a default node that simply includes all the necessary classes for provisioning a virgin server. Part of the Kickstart %post would be to install and invoke Puppet against the provisioning environment. We could do this with separate Puppet Masters, but that feels like more overhead for little added benefit in our scenario. Cheers, Scott -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. 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.
