I''m considering writing some new-user tips -- something brief,
focusing on writing manifests. Ideally, I will put it on the wiki
when it''s in reasonably good shape.
I''m interested in your comments about whether this would overlap too
much with the existing tutorial material, and I welcome any tips you
might want to contribute. I also welcome any commentary about the
tips I''ve already got:
1. Start small. Begin with a manifest that controls just one thing,
via one of the built-in resource types. Host, File, and Service are
good choices for your first managed resource.
2. All resource declarations and variables should go inside classes.
No exceptions.
3. All classes should go inside modules. No exceptions.
4. Avoid virtual and exported resources (@resource {...} or @@resource
{...}) until you have a good grasp of the rest of the Puppet
language. These frequently confuse people who don''t understand the
tao of Puppet.
5. Avoid defined types (introduced via the ''define'' keyword)
until you
have a good grasp of the rest of the Puppet language. These are
syntactic sugar, with a gotcha or two mixed in. New users can better
avoid the gotchas if they first acquire a good grasp other parts of
the language.
6. Follow the style guide. At worst, write your own style guide and
follow that.
7. With Puppet, you influence the order in which resources are applied
via the "require" and "before" metaparameters. Use them
where
necessary (and only where necessary).
8. Use an SCM system such as Subversion or git to track and manage
your 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.
jcbollinger wrote:> 2. All resource declarations and variables should go inside classes.Unless you''re using external nodes, I don''t see a problem with using resources directly in a node. -scott -- 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.
''lo, ----- "Scott Smith" <scott@ohlol.net> wrote:> jcbollinger wrote: > > 2. All resource declarations and variables should go inside > classes. > > Unless you''re using external nodes, I don''t see a problem with using > resources directly in a node.beginners wont know, it''s a helpful tip since most eventually will want to use tools like dashboard/foreman and they''ll regret not knowing it then :) here''s some more: Easily changable exec''s: When creating an exec resource do not put the command in the resource name, imagine this hypothetical example: exec{"do_complex_stuff": command => "/some/command --with --lots --of --arguents" } file{"/etc/foo": before => Exec["do_complex_stuff"] } The temptation is to do the simple thing and just put the command as the name of the exec, the effect of this is if you ever need to change the command you also have to go find all places that has relation ships based on the full command, using a short descriptive name makes everything more readable and managable Don''t leave out important properties on file{}: If you do not specify owner, group and mode on a file it will default to whatever is on the souce, this is often not what u want and will cause confusion. -- R.I.Pienaar -- 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.
R.I.Pienaar wrote:> beginners wont know, it''s a helpful tip since most eventually will want to use tools like dashboard/foreman and they''ll regret not knowing it then :) >Sure, but unless the exception is noted, some people may never find out. -scott -- 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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I don''t know if I completely agree with #3. I tend to think that modules are abstractions that are not installation dependent and all installation dependent things go into your site manifests. So, it''s very logical to have local site classes (that could go under a site module, yes) but that, in general, modules should be as abstract as possible for flexibility. Trevor On 01/12/2010 04:42 PM, jcbollinger wrote:> I''m considering writing some new-user tips -- something brief, > focusing on writing manifests. Ideally, I will put it on the wiki > when it''s in reasonably good shape. > > I''m interested in your comments about whether this would overlap too > much with the existing tutorial material, and I welcome any tips you > might want to contribute. I also welcome any commentary about the > tips I''ve already got: > > 1. Start small. Begin with a manifest that controls just one thing, > via one of the built-in resource types. Host, File, and Service are > good choices for your first managed resource. > > 2. All resource declarations and variables should go inside classes. > No exceptions. > > 3. All classes should go inside modules. No exceptions. > > 4. Avoid virtual and exported resources (@resource {...} or @@resource > {...}) until you have a good grasp of the rest of the Puppet > language. These frequently confuse people who don''t understand the > tao of Puppet. > > 5. Avoid defined types (introduced via the ''define'' keyword) until you > have a good grasp of the rest of the Puppet language. These are > syntactic sugar, with a gotcha or two mixed in. New users can better > avoid the gotchas if they first acquire a good grasp other parts of > the language. > > 6. Follow the style guide. At worst, write your own style guide and > follow that. > > 7. With Puppet, you influence the order in which resources are applied > via the "require" and "before" metaparameters. Use them where > necessary (and only where necessary). > > 8. Use an SCM system such as Subversion or git to track and manage > your manifests. >- -- Trevor Vaughan Vice President, Onyx Point, Inc. email: tvaughan@onyxpoint.com phone: 410-541-ONYX (6699) - -- This account not approved for unencrypted sensitive information -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAktNNyAACgkQyWMIJmxwHpSXiQCgrN0g7Kl/CFexFNsX2dp0skSR hYYAoKwX4WA/1iymMQNHgg3oIGwiRk9P =06Bh -----END PGP SIGNATURE----- -- 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 Jan 12, 5:01 pm, Scott Smith <sc...@ohlol.net> wrote:> R.I.Pienaar wrote: > > beginners wont know, it''s a helpful tip since most eventually will want to use tools like dashboard/foreman and they''ll regret not knowing it then :) > > Sure, but unless the exception is noted, some people may never find out.Your comments are much appreciated, and your point is well made. My objective, however, is not a general best practices document, but rather a help for newbies to get started on the right foot. I can see how some of my initial tips might read otherwise, so I''ll make that clearer in my next draft. John -- 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 Jan 12, 8:59 pm, Trevor Vaughan <tvaug...@onyxpoint.com> wrote:> I don''t know if I completely agree with #3. > > I tend to think that modules are abstractions that are not installation > dependent and all installation dependent things go into your site manifests. > > So, it''s very logical to have local site classes (that could go under a > site module, yes) but that, in general, modules should be as abstract as > possible for flexibility.I guess I have a different view of modules: from my perspective, they are first and foremost a mechanism for organizing and packaging manifests. They are the best vehicle for packaging and distributing site-independent manifests, but I don''t see value in discouraging site- specific ones. I will soften the "no exceptions" in #3, but I do think that newbies are best off learning early how to write modules, and that modules are the right place for most code, including site- specific code. -- 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.
>1. Start small. Begin with a manifest that controls just one thing,via one of the built-in resource types. As someone who started using puppet in november my thoughts on #1 are. Encourage people to gain language experience through writing manifest scripts. Putting puppet in the bang line of the manifest and executing it like a shell script ensures a very short feedback loop when learning. This way the new users get''s some tangible understanding before going off to wrangle with puppet server and client setup. Also IMHO new users should be encouraged to embrace modules early. As my understanding of puppet grows I''m realizing that some of my early design (un)decisions would be more cumbersome to cleanup without modules. Just as background I am totally over the top about directory organization and I arrange my man pages alphabetically so modules appealed to my strict sense of organization/compartmentalization. To get off the ground the resources that helped me the most are (in no order) the stanford best practices guide, example 42''s model, James book, this group (scott), the wiki and writing "puppet" scripts. HTH. Derek. -- 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.