This document discusses improving the reusability of configuration management through better design of cookbooks and resources in Chef. It identifies common pain points like lack of platform support and standard interfaces. The document proposes focusing on resources by standardizing their interfaces, isolating data and logic, and providing resources for common tasks to make configuration management more reusable and delightful.

1. Chef Reusability!
Config Management Camp!
Ghent, Belgium!
February 2015

2. Sean OMeara!
sean@chef.io!
@someara

3. whoami

4. Part 1

5. Things that are true

6. New Chef users
expect community
cookbooks to
just work

7. Especially the Chef
maintained cookbooks

8. This is not the current
state of things

9. This leads to sadness

10. We must repair it

11. People copy patterns

12. The status quo cannot
be allowed to continue

13. Common pain points
https://www.flickr.com/photos/kwl/4595324641

14. Platform and version
support

15. Weak scoping

16. No standard interface

17. Compilation phase work

18. Needing chef-rewind

19. Attributes and precedence

20. Pattern proliferation

21. The path out of the darkness
https://www.flickr.com/photos/71267357@N06/15864687537

22. Change how cookbooks
are written

23. systems
beliefs! behaviors

24. Standardize interfaces

25. Eliminate the pain points

26. Focus on resources

27. Make it super easy!
to write resources

28. Ship resources for ALL
THE THINGS

29. Copy better patterns

30. Make it fucking
delightful

32. Part 2

33. Simple design patterns
https://www.flickr.com/photos/pollock/4172865252

36. You just separated data
from code

37. You also just built an
interface

38. Complex design patterns
https://www.flickr.com/photos/alanosaur/6417040565

41. This is where things
get weird

42. amazon
debian-6
debian-7
ubuntu-10.04
ubuntu-12.04
ubuntu-14.04
centos-5
centos-6
centos-7
freebsd-9
freebsd-10

43. Debconf!
Docker!
LaunchD!
Runit!
SMF!
Simple!
SystemD!
Sysvinit!
Upstart!
Windows Services

44. There is a large amount
of variation between
software versions

45. There is an insane amount
variation across platforms

46. These differences need
to be handled
somewhere

47. Early techniques did
everything in the recipe

48. data
resource
pattern

49. Later techniques
focused on isolation

50. Resource pattern
isolation

52. private
recipes by
convention

53. Resource data isolation

56. We now have decision
logic in our interface

57. Default values often
need to be computed

58. Doing this in the
interface leads to
sorrow

60. We need a better way

61. Consumption Patterns
https://www.flickr.com/photos/ektogamat/2578779839

66. Why resources are best
https://www.flickr.com/photos/cross_stitch_ninja/4932950637

67. node attributes
roles
environments
databags
are nice to haves

68. They drive data about
resources

69. Resources are
fundamental

70. Resources are strongly
scoped

71. Resources have a
standardized interface

72. Resources have types,
names, and parameters

73. Type

74. Name

75. Parameters

76. Resources have
identities

78. Resource can see each
other

79. Promise to
talk

80. Promise to listen

81. Resource behave the
same across platforms

85. Resource can have
multiple providers

87. Writing simple resources

88. yum

89. </switches github>

90. Writing complex resources

91. mysql
httpd

92. </switches github>

93. fin