----- "Paul Lathrop" <p...@tertiusfamily.net> wrote: > Hi Puppeteers, > > I spent some time tonight making a first pass at what I hope will > eventually be a good replacement for the current "Puppet Best > Practices" page on the wiki. I know this needs *tons of work, but I > hit a good pausing point and decided it was time to ask for feedback > and contributions. The idea here is to provide some overall > guidelines > to help newcomers to Puppet establish good habits as well as get the > most out of Puppet, and especially to highlight some common mistakes > and how to avoid them. > > Please take a look and flame away. I need feedback, both positive and > negative, as well as input as to what the Best Practices actually are > (Volcane, I'm looking at you!). I especially need to flesh out that > final section.
I was hoping to redraft this myself when 0.25 came out, but looks like you've beat me to it. Sadly, time doesn't allow me to follow up as closely with the user list as I'd like, (my participation with Puppet as been limited lately to the asynchronous storeconfigs work we've contracted). Here are some comments to consider: * A lot of this does read more like an introduction to Puppet and Puppet concepts, so some of this might need to be broken away elsewhere. * While classes aren't object-oriented, I think treating them as if they are isn't necessarily a bad thing either. Ultimately, when you inherit you are only given yourself permission to override the declared resources, but I also find it to be a good idea to keep this kind of modeling to properly represent what is happening. Ergo, when one class is a derivative of another, I find it better to inherit instead of include, even if I am not overriding a declared resource, simply because modeling shouldn't be a function of what features you are using. * While one shouldn't overuse dependencies, I wouldn't put notify and subscribe in the same boat since they are functionally useful for things besides trying to make Puppet do something in a particular order. I think the intent was just to relate the two parameters to before and require but I would recommend removing it or relocating it so we don't give the impression that using notify or subscribe is a bad idea. * Because of complexity of how and when classes are interpreted, aren't variables often a tricky thing to play with if you are planning to change their values in later scopes? * Lastly, perhaps this is still my OCD, but I'm still a fan of the style guide. Without it, I dont' think our manifests would be as clean and legible as they currently are. -- Digant C Kasundra <dig...@stanford.edu> Technical Lead, ITS Unix Systems and Applications, Stanford 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
