Inspiration
I have been asked on how to use Chef with Cisco switches, hardware timeservers and NetApp storage systems for years.
In many cases, REST APIs are available and would be a good match for Desired State configuration - so why not marry those two?
What it does
With the output of this project, coding knowledge is barely needed for most RESTful APIs and writing/maintaining collapses down to a few additional rest_*
DSL statements.
To demonstrate this as a viable approach, I created a NetApp Platform Support Pack (PSP) - which is a cookbook providing OS platform detection, Ohai plugins, custom resources and helpers to configure NetApp ONTAP systems with Chef. Lowcode-style.
Under the hood, it creates an (abstract) RestResource as a specialized type of Chef::Resource
, which forms the base for implementing vendor-specific resources on top. It provides REST helper functions (get/post/patch/...), supports URL templates (/api/resource/{name}
) and their mapping to custom resource properties and maps properties and JSON entries automatically. It also provides extension points for more complex tasks.
How I built it
Base of everything are several of my PRs to Chef Infra/Ohai/Train over the last years. I also used my 2020 train-rest
driver as transport/authentication/session layer.
On top of this, I created a "Chef Shim" with the functionality and a generic RestResource which could be merged into the Chef Infra core for this capability.
Using the Chef Shim, I then add the example NetApp ONTAP Platform Support Pack including helpers, multiple Ohai plugins, 25 Chef resources and (as an example) a platform-specific REST API authenticator.
And to demo it all, I added a small demo recipe to set up a cluster and e.g. publish an iSCSI target on it.
Challenges I ran into
- some typos deep in the Chef Infra Client code show that apparently nobody has tried this before (fixed via PR on Ohai 17.7)
- configuring a "Chef Runner" (which configures non-agent systems) was confusing due to not being able to specify the Train Transport in /etc/chef/credentials (fixed via PR on Chef 17.7)
- Chef Compliance Phase is not yet Target Mode-capable :-(
- time was not enough to make it "perfect" and extend the Custom Resource DSL instead of using LWRP style in
libraries/
Accomplishments that I'm proud of
- extensions to the Custom Resource DSL make writing REST resources easy as little coding knowledge is needed
- principle of adding a vendor-specific abstract base resource between the new Chef REST Resource and individual resource implementation to handle vendor specifics
- covering use-cases from more than the NetApp API only (e.g. custom authenticators enable Redfish/F5)
- sneakily switching OS and Platform detection in Ohai (
collect_data :ontap
)
What I learned
I seriously need to learn more about Ruby meta programming. I felt dumb sometimes and kind of heard Lamont yelling at me in my head... ;-)
On a serious note: I had no NetApp knowledge before, but will hold multiple of their certifications when the Hackathon results are announced. Yay.
... and I finally understood how Custom Resource DSL works internally.
What's next
- discuss and adjust the abstract REST Resource for possible inclusion in Chef Infra Client
- Fix Chef Compliance Phase, add the corresponding InSpec
rest
resource and add custom InSpec for the NetApp PSP - develop "v3" resources to leave all Ruby-isms behind and go full Custom Resource DSL (be gone,
class
!) - spinning off the NetApp PSP into a separate project maintained via my employer (Chef Principal Partner + NetApp Partner)
Built With
- chef
- netapp
- ohai
- ontap
- rest
- ruby
Log in or sign up for Devpost to join the conversation.