|
Session Title: Cookbook Style Guide Discussion
Convener:
Michael Leinartas
Participants:
Summary of discussions:
The discussion touched on a number of common cookbook patterns, but didn't get to the point where the contents of a "style guide" were discussed or enumerated.
Discussion notes:
Misc criteria for usability of 'library-style' cookbooks
- Easily shareable
- Useful to others
- Environment aware
- LWRPs are very good
- Can make some reasonable assumptions
- Configuration items as attributes
- Ability to easily swap in new templates - usually a good idea
Plugins
- No way to do this right now, but not a very difficult implementation
- Ability to subclass built-in resources and other LWRPs in an LWRP
- Plugins as a way to create hook points/callbacks
- Cookbooks can be more generic and defer specific implementation to plugins (e.g. database replication strategy)
- Related: All resources should have pre/post hooks
@node vs passed in variables in templates?
- Not resolved, some contend that @node should never be used as it's dangerous and has potential for side-effects
- Passed in variables are a way for the cookbook author to define an api into the template
Miscellaneous points discussed
- Attribute references should be strings (node['attribute']) - all other methods are discouraged and deprecated
- Dividing line on what should and should not be an LWRP is fuzzy - this could use some fleshing out by someone
- IP addresses: first interface vs second?, cloud IPs or not? This needs some kindof helper
- Platform case statements are a repeated complaint, no good solution at this point
- Direction on how to properly architect a cookbook, so that internal data is stolred separately from core cookbook files that might be re-shared upstream.
What will we do now? What needs to happen next?
Opscode has begun work on a Cookbook Style Guide Draft
|