Generic REST Resource Support for Chef - eg for NetApp ONTAP

• 

  ontap_ems_destination resource showing custom property maps

• 

  ontap_igroup resource showing simple property maps

• 

  ontap_svm resource showing complex property maps and additional actions

• 

  Example cookbook for cluster base setup

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