On Monday, February 2, 2015 at 2:58:51 PM UTC-6, Trevor Vaughan wrote: > > Inline.... > > On Mon, Feb 2, 2015 at 3:24 PM, Garrett Honeycutt < > [email protected] <javascript:>> wrote: >
I'd like to vote for putting all validation at the bottom of the file. > > Honestly, we're getting quite heavy in the amount of cruft in the files in > general. > Agreed. > == Section 10.2.7 > > > I tend to order things in resource alphabetical order because then, if I'm > looking for a file resource, it's in the 'F' section. And I still like the > fact that order doesn't matter in Puppet unless I tell it to. Accordingly, > should I happen to break my order accidentally, I really don't want to care. > > Although I do tend to order my resource declarations as described by 10.2.7, I agree that it is not a particularly useful as a style guideline. I use that order because it makes sense to me and helps me find things, not because of the functional implications (that anyway don't always apply), and I don't stick to that order rigorously. I'd argue that a mandate to order resource declarations specifically by relative order of application is counter-productive. It de-emphasizes the importance of using relationships to specify application order, and may sometimes mask bugs arising from failure to declare needed relationships. > > >> == Section 10.6 >> Suggest that while having required parameters for defines is OK, having >> them for classes is not. There should never be required parameters for a >> class. This breaks the ability to `include` a class. >> >> > No, I disagree here. There are (many) times that I *need* you to give me a > parameter, I can't make one up that is magically correct. Moving this to a > define-only state means that we have to start slinging around singleton > defines which is what parameterized classes got us away from. > > I'd rather have my compile break than end up with a system doing something > nonsensical, particularly when the security of the system may be at risk. > I think the middle ground here would be best: the guide should recommend *minimizing* the number of mandatory class parameters. Although I very much favor declaring classes via 'include', I acknowledge Trevor's point, and I observe that mandatory class parameters can be satisfied by automated data binding (i.e. Hiera), so they don't altogether *break* the ability to 'include' such a class, they just limit it. John -- 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/5649c5c9-7ce3-4467-874b-ce2c55f3ad5c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
