Should a page in the wiki be created to describe a good common.pp? For example, Luke states in the documentation for ''Exec'' that "...there is a strong tendency to use exec to do whatever work Puppet can''t already do; while this is obviously acceptable (and unavoidable) in the short term, it is highly recommended to migrate work from exec to native Puppet types as quickly as possible." Can we (as a community) use common.pp to do this? We could define functions (such as something similar to cfengine''s HashCommentLinesContaining), users could start using them, and Luke could mark whether the function will become native to Puppet after the API settles down. For example, I have defined backup-dir so that all I have to do is this: backup-dir { "SaveConfigs": path => "/", directory => "etc", destination => "main", compression => 2; }
On May 17, 2007, at 9:09 AM, Michael Manry wrote:> Should a page in the wiki be created to describe a good common.pp? > For example, Luke states in the documentation for ''Exec'' that > "...there is a strong tendency to use exec to do whatever work Puppet > can''t already do; while this is obviously acceptable (and unavoidable) > in the short term, it is highly recommended to migrate work from exec > to native Puppet types as quickly as possible." > > Can we (as a community) use common.pp to do this? We could define > functions (such as something similar to cfengine''s > HashCommentLinesContaining), users could start using them, and Luke > could mark whether the function will become native to Puppet after the > API settles down. > > For example, I have defined backup-dir so that all I have to do is > this: > backup-dir { "SaveConfigs": > path => "/", > directory => "etc", > destination => "main", > compression => 2; > }It seems like the best approach is to focus on modules as the unit of redistribution. I haven''t yet considered shipping a stdlib of modules, but we should at least start talking about it. -- In our civilization, and under our republican form of government, intelligence is so highly honored that it is rewarded by exemption from the cares of office. --Ambrose Bierce --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On 18.05.2007, at 16:17, Luke Kanies wrote:> On May 17, 2007, at 9:09 AM, Michael Manry wrote: >> Can we (as a community) use common.pp to do this? We could define >> functions (such as something similar to cfengine''s >> HashCommentLinesContaining), users could start using them, and Luke >> could mark whether the function will become native to Puppet after >> the >> API settles down. >> >> For example, I have defined backup-dir so that all I have to do is >> this: >> backup-dir { "SaveConfigs": >> path => "/", >> directory => "etc", >> destination => "main", >> compression => 2; >> } > > It seems like the best approach is to focus on modules as the unit of > redistribution. I haven''t yet considered shipping a stdlib of > modules, but we should at least start talking about it.I also do think that a standard set of configurations would be very helpful. I would not distribute it with puppet itself, though. Since configuring an operating system does not necessarily has to do somehting with the tools you use to configure it, it would be wise to find a way to distribute configurations in an easy (CPAN-like? SVN- repositories, etc....) way. This way everybody can select what she needs. I think it would be wrong to distribute a huge amount of predefined rules with puppet. This way, it would be hard to start using. One would have to figure out which rules are relevant to him and discard the rest. What about setting up a svn-repository, say "puppet-conf", where people can commit their script and snipplets. Clearly this needs a structure, something like: unstable/ testing/ stable/ (sorry for the debian thinking here), would make sense. Everybody could submit to "unstable". This code needs to be tested and changed, such that it can be transferred to "testing", where a smaller group of people have commit rights. Here, only code that obeys the following rules can be commited: - basic test successful - documentation of the module in the module - obeys the ''Best practices'' After undergoing further tests and a revision from the "stable" people, the module is integrated into stable: - proper documentation (the module should be selfcontained, no: "read here: http://" and such) - proper formatting of code - ''best practices'' enforced - categorized: (something like ''common'' or ''debian'' or ''package-xyz'') These are the first ideas concerning this topic. I think it is important to build such a repository. I guess that most of the standard configuration for an operating system has already been done once or twice by the puppet users. It would be very important to have this code shared. Thanks, udo. -- ---[ Institute of Cognitive Science @ University of Osnabrueck ---[ Albrechtstrasse 28, D-49076 Osnabrueck, 969-3362 ---[ Eyes: http://www.zoide.net/ ---[ Ears: http://www.auriculabovinari.de/
On May 19, 2007, at 2:39 AM, udo waechter wrote:> > I also do think that a standard set of configurations would be very > helpful. I would not distribute it with puppet itself, though. Since > configuring an operating system does not necessarily has to do > somehting with the tools you use to configure it, it would be wise to > find a way to distribute configurations in an easy (CPAN-like? SVN- > repositories, etc....) way.Yep, we''re working on it (PRM, or something like it), and it''s a big priority for me this summer.> This way everybody can select what she needs. > I think it would be wrong to distribute a huge amount of predefined > rules with puppet. This way, it would be hard to start using. One > would have to figure out which rules are relevant to him and discard > the rest.True to some extent, I guess.> What about setting up a svn-repository, say "puppet-conf", where > people can commit their script and snipplets. > Clearly this needs a structure, something like: > > unstable/ > testing/ > stable/[...] Hmm. I think in the beginning we''ll focus on a repository that doesn''t include the release names. Maybe once the repository is mature, we can build releases based on specific versions of specific modules, but I don''t think we''ll be doing that out of the gate. Part of it is definitely that Puppet users will want to have their own control over which version of a given module makes it into a given release. Puppet should explicitly support releases (or environments, or whateve we end up calling them) in the next couple of months, so that will make this easier.> These are the first ideas concerning this topic. I think it is > important to build such a repository. I guess that most of the > standard configuration for an operating system has already been done > once or twice by the puppet users. It would be very important to have > this code shared.I completely agree, and that was certainly part of my goal in writing Puppet -- make it easy to share this kind of work. I''m trying, but I can''t do it all myself... -- I used to get high on life but lately I''ve built up a resistance. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com