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
Share this project: