ATXPUG Meet-up slides from our discussion on ideas to help manage puppet complexity - from development concepts to design / coding standards.

1. Austin Puppet Users Group
(ATXPUG)
Managing Puppet Complexity

2. Modules & Complexity
Complexity is generally used to characterize
something with many parts where those parts
interact with each other in multiple ways.

3. Style
• Make quality a requirement
• Know when to stop (don’t over optimize)
• DRY – Don’t Repeat Yourself

4. DRY – Don’t repeat yourself
• Imposed Duplication – Apparent lack of
choice
• Inadvertent Duplication – Not realize that
they’re duplicating information
• Impatient Duplication – lazy / duplicate
because it seems easier
• Interdeveloper Duplication – Multiple people
on teams / multiple teams.

5. Code
• Keep low level knowledge in code
• Reserve Comments for high level expectations
• Foster an environment where it’s easier to
find and reuse existing stuff than to write it
yourself.

6. Avoid Global data
• Every time you reference global data it ties
you to the other components that share data
– frowned upon since 2.x days but still in a lot
of puppet code

7. Orthogonal - Safe to Fail
• Independent / lightly coupled systems
– Eliminates effects of unrelated things
– Design self contained things
• Increased productivity & contained risk

8. Prototype (experiment)
• Architecture
• New functionality in existing systems
• Structure or contents of external data
• Third party tools or components
• Performance issues
• User interface / experience / design

9. Experiements
• Worry less about correctness, completeness,
robustness and style.
• Focus on design / definition
• Is coupling minimized?
• Can you identify potential sources of
duplication?

10. Style Guides
• https://docs.puppetlabs.com/guides/style_gui
de.html

11. Test
• Loosely coupled systems easier to test –
interactions between components are limited.
– Unit testing is easier
– Test in CI pipeline
• Beaker / rspect / puppet lint

12. Refactor
• Avoid code rot. Don’t let bad code fester and
turn all your code into abandonware

13. It’s code
• Version control
• Test
• Refactor
• Share.
• forge

14. Module Template
• Puppet Module Generate – use the boiler
plate
• Use Garethr’s boiler plate – nice & updated
https://github.com/garethr/puppet-module-
skeleton (more assumptions though)

15. Data Separation
• Some use hiera.. Me no like
• ENC
– Puppet PE
– Foreman
– Homebrew
– ?
• Single source of truth? How?

16. Parameterized Classes
• Great for ENCs
• Easy to set default values
• Portable / Shareable

17. Class Inheritance
• Use within a module to reduce repetition
(DRY)
• Inheriting from other modules decreases
modularity, but hard to avoid
– ENC confusion

18. Code Defensively
• Catch unexpected events before they break
things – gracefully bow out if you don’t
support platform
• Puppet Future parser helps –
– Line error failure reporting
– Type checking (out of stdlib)

19. I wish
• More modules exposed puppet resources
• Augeus (or similar) was internalized across
every platform so there was an easy meta
catalog instead of is osfamily = yaddy yaddy
yadda
• Open source puppet had strong direction.. 3.7
PE is out.. What next for OS?

20. Discussions
• I’m out of slides, time for interaction