Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
1,529
edits
ReleaseEngineering/PuppetAgain/HowTo/Hack on PuppetAgain: Difference between revisions
Jump to navigation
Jump to search
ReleaseEngineering/PuppetAgain/HowTo/Hack on PuppetAgain (view source)
Revision as of 00:03, 11 July 2012
, 11 July 2012no edit summary
No edit summary |
No edit summary |
||
| Line 62: | Line 62: | ||
* Even if all of the FooAPI servers are running OpenSolaris, $::operatingsystem=="Solaris" does not mean this is a FooAPI server. OS does not imply role. Roles are defined in node declarations, by including <tt>toplevel::*</tt> classes. | * Even if all of the FooAPI servers are running OpenSolaris, $::operatingsystem=="Solaris" does not mean this is a FooAPI server. OS does not imply role. Roles are defined in node declarations, by including <tt>toplevel::*</tt> classes. | ||
* It can be tempting to put "just one resource" into an already-existing class. User::builder seems to be a popular target. Adding new classes is easy, and avoids surprises. If the resource you're adding isn't obviously tied to the name of the class you're adding it to, put it in another (probably new) class. | * It can be tempting to put "just one resource" into an already-existing class. User::builder seems to be a popular target. Adding new classes is easy, and avoids surprises. If the resource you're adding isn't obviously tied to the name of the class you're adding it to, put it in another (probably new) class. | ||
== Config Files == | |||
* For file-resources where you can easily implement a run-parts format design, do so, rather than modify the global config. | |||
** Examples crontab vs cron.d/*, http.d. | |||
* You should specify the parent dir to purge and recursive, so that when you remove a resource from puppet it removes itself from the machine. | |||
* The crontab resource has complex gotchyas, *always* use cron.d/* for cron. | |||
* config resources which are run automatically should explicitly depend on the Classes they need to run properly. | |||
= Nit-Worthy Code Style = | |||
While everyone will have different opinions on the best Coding Style, one thing we can all agree on, life is better when we all agree. So the following are Nit's we should all strive to adhere to, but exceptions can be made with good reasoning. (mistakes can sneak in, if so, just edit them out next time you touch that area of code) | |||
== Whitespace and Tabs == | |||
* '''TABS''': NEVER in a puppet manifest file. ONLY when necessary in other files. | |||
* '''Trailing Whitespace''': Shouldn't exist. | |||
* '''EOL''': Always Unix style line-endings. | |||
* '''EOF''': Always include a newline at EOF | |||
* '''Indentation''': Four Space indents. | |||
== Comments == | |||
* We prefer the <code>#</code> style comments throughout, C-Style is frowned upon. | |||
* Manifests that are not very obvious by their name should have a very brief comment at the top of the file describing it, these comments are informative, normative reference is the wiki docs. | |||
* When it helps understanding of why something is in the manifest (or not in the manifest) please include brief comment saying so. | |||