That's not my puppet - Things *not* to do (and some alternatives)!
2020-02-04, 17:40–18:30, B.1.015

Whilst best practices do involve over time (and sometimes 'advice' changes completely), there's also the other end of the spectrum where
style-guides are ignored, house 'styles' take over and the anti-patterns and worse prevail.

Fed up with being told 'it works, why shouldn't I write puppet this way?', I present a selection of puppet code witnessed in the wild.
(All from non Puppet Enterprise setups. PE users all write beautiful code and none of it ever looks like what follows, right?)

From just old code, (with better and simple to achieve improvements), to the darn right ugly, stupidly fragile or just plain broken.
- Old constructs (from a land before puppet 4) (create_resource, anchor etc).
- Abuse of hiera
- Too much data
- The super hash. $data = hiera_hash('data') $jdk_version = $data['oracle']['java']['jdk']['version']
- Calling hiera from templates with local scope vars used in the hierarchy
- duplication
- Abuse of Exec.
- Why use a file resource when you can have an exec call mkdir?
- Replacing an old script with 30 chained execs
- Ruby based facts that shell out to hostname and grep
- Mono repos with forge modules seemingly randomly committed in then modified in place.
- Writing everything from scratch (even when really simple and popular forge modules exist)

Finally, is there anything we can do about this (other than venting frustration at conferences?).