-
Mixlib-shell out interface :: A portable , cross platform command execution module. How to use it with any arbitrary code, how chef interfaces with it (shellout, shellout! etc)
-
Mixlib-Cli :: The awesome command line argument processor. How to use it with any arbitrary program , pitfalls associated with reusing classes that uses mixlib-cli
-
A generic overview of the chef rest class (Chef::Rest) and main domain objects (Node, Role, ApiClient etc). How to access them from any arbitrary scripts (#load, #list . #search etc).
-
Anatomy of a chef run (revisited with chef internal) :
- setup phase (logging setup, configuration setups, client registration, getting a node's runlist)
- cookbook syncing,
- building the node (running ohai, merging the attributes obtained from cookbooks)
- compile phase .. (building the extended run list, .. resource_collection)
- execution phase .. notifications resolution
- handlers execution (report/exception) & optional node.save
-
Digging deep inside a run context: what it holds, which all chef core components (e.g runner, provider etc) needs run context to function
-
Digging deep inside a provider (we can talk about resource, but theres not moch).
-
the notion of convergence, how why_run works, how to make a custom resource (may be lwrp) why_run compatible
-
how the action_* works
-
Knife plugin development
-
how to write knife plugins that can be reused by other knife plugins? what are the pitfalls (Mixlib::Config gotchas). What to avoid, & other tricks (like dep loading, config settings etc).
-
using ui object for messages, warning etc
-
using ui.output & automagically support -Fj
-
The events api: Chef has an awesome events api . it provides event hooks/callbacks to a wide set of states (like cookbook sync begin., chef run starts etc). A brief overview of what all events available and a small example on how to hook your logic against a particular event.
-
Formatters. The formatter api , writing a custom formatter .
-
Ohai .. extending ohai, pitfalls, apis etc.
-
A brief overview of Mash , ChefFS, Mixlib::JSONCompat . Why these modules are used inside chef , instead of vanilla ruby alternatives? And why someone extending chef should use these components
-
Debugging chef
-
chef applications (chef-client, chef-solo etc) and
-l debug
option -
knife plugins and increasing verbosity (-VV)
-
chef-shell
-
using pry to debug chef run.
-
rbtrace with chef
- Configure chef from irb and run a search
- Enlist all the nodes
- Get a particular node and save an attribute in it.
- Use mixlib-shellout to tail a log and stream its output
- Manually create a run context , assign an individual package resource and invoke a chef run.
- Hook a custom call back against chef run start event
Probably need John Keiser to talk about ChefFS, I'm totally ignorant of how it works. But also note that it's not an alternative to
File
and friends, it's a thing that provides file/path type semantics on top of a chef repo or chef server.