Austin Puppet Users Group

(ATXPUG)

Managing Puppet Complexity

Modules & Complexity

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

Style

• Make quality a requirement

• Know when to stop (don’t over optimize)

• DRY – Don’t Repeat Yourself

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.

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.

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

Orthogonal - Safe to Fail

• Independent / lightly coupled systems

– Eliminates effects of unrelated things

– Design self contained things

• Increased productivity & contained risk

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

Experiements

• Worry less about correctness, completeness, robustness and style.

• Focus on design / definition

• Is coupling minimized?

• Can you identify potential sources of duplication?

Style Guides

• https://docs.puppetlabs.com/guides/style_guide.html

Test

• Loosely coupled systems easier to test –interactions between components are limited.

– Unit testing is easier

– Test in CI pipeline

• Beaker / rspect / puppet lint

Refactor

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

It’s code

• Version control

• Test

• Refactor

• Share.

• forge

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)

Data Separation

• Some use hiera.. Me no like

• ENC

– Puppet PE

– Foreman

– Homebrew

– ?

• Single source of truth? How?

Parameterized Classes

• Great for ENCs

• Easy to set default values

• Portable / Shareable

Class Inheritance

• Use within a module to reduce repetition (DRY)

• Inheriting from other modules decreases modularity, but hard to avoid

– ENC confusion

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)

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 yaddyyadda

• Open source puppet had strong direction.. 3.7 PE is out.. What next for OS?

Discussions

• I’m out of slides, time for interaction