Puppet users - Jun 2008 - Question about puppet vs puppetd

So I am going through our new dev workstation build for internal
developers.. The main features of this is a RH5 W/S, with OpenVZ for
VE''s, building in our codebase with Maven 2.1.  The HW Spec is beefy
with a dual core proc, 8GB RAM, and 1 TB HD (two 500 MB with lvm).
The idea is to run multiple virts that can mimic a PRD server for
testing, etc.  So Instead of many shared DIT, SIT, UAT, PRD, DR
servers a dev can do a lot of the DIT, SIT work on their own box.

So what I am trying to build with puppet is after the machine is
kickstarted, we configure everything for the main machine - UNIX
Security Baseline (working), ssh, subversion, etc (all working), the
openvz Master config (80% working), transparent proxy, etc.

Now I want to build a bunch of puppet configs that are run one time or
only when building a new virt under openvz... Do I follow the module
formula but leave out loading the file.pp in the init.pp for that
module?  I am talking about re-writing all the /etc/vz/dists/scripts
as pp files... So I guess my question is - Does Best Practices
differentiate between modules mananged by puppetd and stand alone
puppet manifests?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On 6/11/2008 10:27 AM, Jeff Leggett wrote:
> Now I want to build a bunch of puppet configs that are run one time or
> only when building a new virt under openvz...
(Unless I misunderstand, which is entirely possible...)

The one-time-only requirement is satisfied when all your puppet actions 
are idempotent. The built-in ones for package installation and removal, 
user management, cron jobs, etc. are already idempotent. So that mostly 
leaves any execs you define -- 
http://reductivelabs.com/trac/puppet/wiki/TypeReference#exec talks about 
this.

It''s a matter of transitioning your execs from "only do this 
non-idempotent action once", which requires some level of manual 
intervention to "see if there''s any evidence that this
non-idempotent
action has already occurred. If not, do it now", which can be run every 
time puppet runs.

The "only when building a new VE" requirement could be handled by 
classing and defining your VE creation, similar to what I do for 
deploying stow packages, or what others do for managing trac and svn 
instances. If I need to formalize how I build VEs with a series of steps 
like "run xen-create-image --lvm --hostname fqdn.of.instance, then copy 
this config file to /etc/xen/fqdn.of.instance, then symlink 
/etc/xen/auto/fqdn.of.instance to ../fqdn.of.instance, and finally run 
xm create /etc/xen/fqdn.of.instance", then I''d make a definition
to do
all of those things in sequence, checking if each step was successful to 
ensure idempotence, and making a dependency requirement from one step to 
the next.

If you need to treat your developers'' virtual servers different than
any
other virtual servers, then you could drop an extra environment variable 
into the VE''s /etc/profile or similar that sets a custom facter 
variable, e.g. "FACTER_ve_in_workstation=true" which would cause later
facter runs to report back "ve_in_workstation => true" and could be
used
in your regular manifests. This assumes that you''d use puppet to manage
the VEs as well as the workstations, of course. If you don''t need to 
treat the developers'' VEs any differently, then you don''t need
the extra
facter fact.

-- 
Mike Renfro  / R&D Engineer, Center for Manufacturing Research,
931 372-3601 / Tennessee Technological University

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---