Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Austin Puppet Users Group
(ATXPUG)
Managing Puppet Complexity
Modules & Complexity
Complexity is generally used to characterize
something with many parts where those parts
interact wit...
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
t...
Code
• Keep low level knowledge in code
• Reserve Comments for high level expectations
• Foster an environment where it’s ...
Avoid Global data
• Every time you reference global data it ties
you to the other components that share data
– frowned upo...
Orthogonal - Safe to Fail
• Independent / lightly coupled systems
– Eliminates effects of unrelated things
– Design self c...
Prototype (experiment)
• Architecture
• New functionality in existing systems
• Structure or contents of external data
• T...
Experiements
• Worry less about correctness, completeness,
robustness and style.
• Focus on design / definition
• Is coupl...
Style Guides
• https://docs.puppetlabs.com/guides/style_gui
de.html
Test
• Loosely coupled systems easier to test –
interactions between components are limited.
– Unit testing is easier
– Te...
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://gith...
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, b...
Code Defensively
• Catch unexpected events before they break
things – gracefully bow out if you don’t
support platform
• P...
I wish
• More modules exposed puppet resources
• Augeus (or similar) was internalized across
every platform so there was a...
Discussions
• I’m out of slides, time for interaction
Upcoming SlideShare
Loading in …5
×

ATXPUG Meetup 11/11/14 - Managing complexity in Puppet Code

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

  • Login to see the comments

ATXPUG Meetup 11/11/14 - Managing complexity in Puppet Code

  1. 1. Austin Puppet Users Group (ATXPUG) Managing Puppet Complexity
  2. 2. Modules & Complexity Complexity is generally used to characterize something with many parts where those parts interact with each other in multiple ways.
  3. 3. Style • Make quality a requirement • Know when to stop (don’t over optimize) • DRY – Don’t Repeat Yourself
  4. 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. 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. 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. 7. Orthogonal - Safe to Fail • Independent / lightly coupled systems – Eliminates effects of unrelated things – Design self contained things • Increased productivity & contained risk
  8. 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. 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. 10. Style Guides • https://docs.puppetlabs.com/guides/style_gui de.html
  11. 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. 12. Refactor • Avoid code rot. Don’t let bad code fester and turn all your code into abandonware
  13. 13. It’s code • Version control • Test • Refactor • Share. • forge
  14. 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. 15. Data Separation • Some use hiera.. Me no like • ENC – Puppet PE – Foreman – Homebrew – ? • Single source of truth? How?
  16. 16. Parameterized Classes • Great for ENCs • Easy to set default values • Portable / Shareable
  17. 17. Class Inheritance • Use within a module to reduce repetition (DRY) • Inheriting from other modules decreases modularity, but hard to avoid – ENC confusion
  18. 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. 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. 20. Discussions • I’m out of slides, time for interaction

×