On Fri, May 16, 2014 at 11:12:15AM -0700, Ramin K wrote: > On 5/15/2014 12:14 PM, Christopher Wood wrote: > >(inline) > > > >On Thu, May 15, 2014 at 11:45:21AM -0700, Ramin K wrote: > >> > >>I'd also like to disagree slightly with Christopher who also > >>posted in this thread. Your profile:: classes are the perfect place > >>for all sorts of site specific nonsense including resources. In > >>fact if you're not sufficiently embarrassed of your profile classes > >>you're probably not taking full advantage of that abstraction > >>layer. I wrote about how I use/abuse them here, > >>https://ask.puppetlabs.com/question/5235/what-goes-in-the-profile-part-of-roleprofile/ > > > >(I think I had this exact conversation when discussing profiles at > >work.) > > > >This is usually where I say: If you have site-specific things you > >should modularize those and add the relevant include statements and > >chaining to the profile, with the data in hiera. > > > >For us that includes a site level in hiera so that hosts at different > >sites get different puppetmasters (server not ca_server), ntp > >servers, resolvers, and so on. This helps us use the mnemonic that > >anything in node yaml indicates either an oddity or an error. This > >will also let us quickly include a module if we need it somewhere > >else. > > > >Of course, your mileage may vary, mine sure has at times. > > Oh good, disagreement. I think much harder when that happens :-) > > We probably agree more than disagree, but the statement that > bothered me was that profile was a place of pure includes and > chains. Sure everything should be modularized, but often the time to > do it is eventually and sometimes never. Generalization should only > happen once you need more than one and fully understand the problem. > Perhaps we could mimic Knuth and say "Premature generalization is a > distraction from automating your production system."
There's a point. Though regardless of my level of understanding I definitely will need more than one (more below.) > I think there is a distinction between small systems and large ones > which affect both our point of views. I run a smallish system that I > own completely. Without dissenting opinions about what should be on > servers I'm free to make sweeping changes to how we manage a daemon > with hardly anyone noticing let alone caring. And because I'm > manpower limited, I'm unlikely to do generalization unless > absolutely needed. > In a larger system many sites, divisions, etc are going to do > things differently and generalization is required much earlier and > often. Also with a larger staff the additional code and complexity > is worth it if it keeps everyone from reinventing the wheel. I think you've hit the nail right on the head. My thinking is definitely influenced by the need to do things at (medium-ish) scale and I won't be interrupted by some random server's nagios tantrum. If it was a choice between perfect profiles and being able to get everything else done too I would definitely make your choice instead (as I have before). As long as it's in git/puppet somebody can read it later and figure out what I was up to. > Ramin > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/537654FF.2000502%40badapple.net. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/20140520171916.GA8659%40iniquitous.heresiarch.ca. For more options, visit https://groups.google.com/d/optout.
