Hi! I'm Amit Borulkar, an engineer here at NetApp in the Converged Infrastructure group. My interactions and conversations with customers yield a common trend that I've observed over the past year: the walls between development and operations are being torn down by DevOps practices.

Once those customers implement DevOps practices, they achieve the following:

  • increased agility
  • better operational efficiency
  • more frequent release cycles

All aspects of the development cycle can be accelerated: source code management, build lifecycle, quality assurance, and the deployment itself can be intricately stitched together through automation via an automation orchestration framework.

The infrastructure component setup can be automated in the very same manner as the development cycle!

How can infrastructure be automated?

Automation typically involves writing scripts in an imperative programming style, where the author specifies a sequence of actions (using the APIs exposed by infrastructure components) for configuring the infrastructure components to a desired end state. To make infrastructure provisioning robust, these scripts need to identify the initial state of the infrastructure and accordingly invoke an appropriate sequence of logic to transition the infrastructure to a desired end state.

  • A workflow might involve multiple resources. A script to invoke proper logic depending on all the possible combinations of initial state of the resources might involve complex logic.
  • Writing comprehensive logic for multiple workflows might be a daunting task.
  • The logic would also need to handle resource dependency tracking among different infrastructure components. (For example, Disk space for a Virtual Machine has to provisioned before it is created).
  • The results of these scripts needs to be consistent among multiple runs and across different infrastructure regions.

Writing these scripts might be cumbersome, error-prone, and they oftentimes require frequent changes based on the dynamic nature of the infrastructure. This situation might lead to an automation paradox where operations staff spend more time managing these scripts than what could be spent solving other business problems.

Declarative state-based automation solves the problem of having to maintain custom scripts. The end user declares the desired end state without having to specify (or even know) the underlying implementation details. Manifests describe the desired end state of the system (in an easy to grasp XML/JSON like syntax) using resources and their list of attributes. Operations staff declare the desired end state in a manifest file, and all the intricacies are abstracted from the operator. These include items such as: invoking the proper APIs based on current infrastructure state, and resource dependency tracking. Bottom line: let the automation take care of that for you.

These manifests can be version controlled using source management tools such as Git. You can use source control to also provide an accurate audit trail of when and where changes to the infrastructure have been performed. Does this mean that the infrastructure configuration itself is now version controlled? Yes! You can reliably switch between different configurations and maintain consistency across your entire infrastructure, no matter how many different items you may respectively have.

Here is a sample manifest file, that creates a NetApp FlexVol and a LUN on a storage appliance running NetApp clustered Data ONTAP:

node 'vserver01.netapp.com' {
    // Create a Volume
    netapp_volume {
        'vol1_iscsi' :
            ensure => present,
            aggregate => "aggr02_node01",
            initsize => "1g",
            state => "online",
            exportpolicy => "exp_vserver01"

    // Create a LUN
    netapp_lun {
            ensure => present,
            ostype => "windows",
            size => '400m',
            spaceresenabled => 'false'

How does FlexPod enable state-based provisioning?

FlexPod is a pre-validated converged infrastructure platform powered by NetApp and Cisco with compute, network and storage components bundled together, which serves as a building block for your datacenter infrastructure. To illustrate the concept of declarative state-based provisioning of infrastructure resources, we will use Puppet's integration with the storage, network and hypervisor components of FlexPod.


Provisioning Storage

NetApp, along with Puppet have jointly developed an open-source module for managing the configuration of NetApp's clustered Data ONTAP operating system. The module has a comprehensive set of resource types defined for it, which allows the management of aggregates, storage virtual machines (SVM for short), network interfaces, and many other aspects of the cluster. The module can also enable access to storage resources using exports, shares and LUNs. The Data ONTAP device module also allows you to manage your data across both on-premises environments and public cloud seamlessly using NetApp's SnapMirror protocol to interconnect those different cloud environments (on-premesis, public cloud, etc) thus enabling NetApp's vision of a Data Fabric.

Complete solution architecture diagrams, information about supported resource types, sample manifests for cluster-scoped operations and SVM-scoped operations for using Puppet with NetApp FAS Storage can be found in a recently published NetApp Technical Report - Using Puppet to Manage Your NetApp Storage.

Be sure to also to check out Puppet modules for other NetApp storage offerings like E-Series/EF-Series and SolidFire.

Managing the Network

Cisco Systems was one of the first vendors to leverage the Puppet device functionality to administer the devices which cannot natively run a Puppet agent. The module allows you to configure VLANs and interfaces consistently across different ethernet switches. A detailed list of the features supported by the module across different platforms can be found here.

Deploying Virtual Infrastructure

VMware vSphere ESXi is one of the most commonly deployed hypervisors across datacenter environments for server virtualization. When it comes to provisioning of virtual infrastructure, VMware has released a VMware vCenter module available via the Puppet Forge. The module allows you to create Datacenters within vCenter, add ESXi hosts, add clusters, manage Datastores, and more.

Note: The modules might not be able provide resource types for each and every infrastructure feature, but they do provide baseline functionality sufficient to establish a base infrastructure by supporting the most commonly performed operations. Due to the modular nature of the Puppet Type/Provider interface, new resource types can be easily added without affecting existing resource types.

What does all this mean?

The result of declarative configuration management using Puppet is a set of manifests that describe the intended end-state configuration of each infrastructure component. Take for instance the execution of a Continuous Integration / Continuous Deployment (CI-CD) workflow: manifest templates would be used to provision storage, (such as a LUN or NFS share containing the source code), then it could be mapped to a VM owned by a developer. The manifest templates could also describe replicating build and test servers on demand from a "golden" test/build server image. Another use case applies to the concept of hybrid cloud. Data can be moved from on-premises to one or more Cloud ONTAP instances, or NetApp Private Storage (NPS) for Cloud, using the Puppet module's "netapp_snapmirror" resource type.

Manifests of small tasks can be grouped together to form a catalog which correspond to an Infrastructure-as-a-Service (IaaS) workflow. The operator is only responsible for changing variable names and applying the catalog. Let's look at a sample catalog which corresponds to a simple end-to-end provisioning workflow. The catalog consists of two manifest files, one for managing clustered Data ONTAP resources (like creating volumes, enabling the NFS service, creating NFS export policy and rules, and so on):

node 'vserver01.rtp.netapp.com' {
    // Creates an export policy  
    netapp_export_policy {
            ensure => present,  

    // Adds rules to export policy  
    netapp_export_rule {
            ensure => present,    
            clientmatch => '',
            protocol => ['nfs'],
            superusersecurity => 'none',
            rorule => ['sys', 'none'],
            rwrule => ['sys', 'none']

    // Enables the NFS server on the Storage Virtual Machine (SVM)
    netapp_nfs {
        'vserver01' :
            ensure => present,
            state => 'on',

    // Creates a NetApp FlexVol
    netapp_volume {
            ensure => present,
            aggregate => 'aggr01_node02',
            initsize => '1g',
            junctionpath =>  '/vol1_nfs',
            exportpolicy => "nfs_export",
            state => "online"

    // Modifies the root NetApp FlexVol policy
    netapp_volume {
            ensure => present,
            exportpolicy => "nfs_export"

The other Puppet manifest manages resources in VMware vCenter (items such as creating a Datacenter, adding hosts, adding NFS datastores, and so on):

node 'agent.rtp.netapp.com' {
    include 'vcenter::package'

    // Create a transport type for connecting to VMware vCenter
    transport {
            username => "administrator@vsphere.local",
            password => "abcxyz123",
            server  => "",
            options => { 'insecure' => true }

    // Create a Datacenter in VMware vCenter
    vc_datacenter {
            ensure => present,
            path => "/DC_NFS",
            transport => Transport['vcenter']  

    // Add Host to the Datacenter
    vc_host {
            ensure => present,
            path =>  "/DC_NFS",
            username => "root",
            password => "abcxyz123",
            transport => Transport['vcenter']  

    // Mount the Datastore to the VMware vSphere ESXi Host
    esx_datastore {
            ensure => present,
            type => "nfs",
            remote_host => "",
            remote_path => "/vol1_nfs",
            transport => Transport['vcenter']

Operations staff are responsible for applying Puppet manifests by running a single command. The infrastructure components (storage and virtualization) are then appropriately configured based on the contents of the manifest, in some cases less than 30 seconds.

These catalogs can be extended further to provide multi-tier service offerings (by having catalogs corresponding to each service level), resulting in infrastructure provisioning being managed though a single manageability plane powered by Puppet.


The ability for IT to adapt to changing business requirements plays a critical role in success of an enterprise. The declarative (tell me what you want) style automation for infrastructure provisioning increases the operational agility by ensuring quick and reliable transitions between different infrastructure configurations.

Infrastructure provisioning through Puppet also enables a centralized resource management plane for managing FlexPod resources (storage, network, and compute), thereby enabling a truly Software Defined Data Center (SDDC).

About Amit Borulkar

Amit is a part of the Converged Infrastructure Group at NetApp where he focuses on all-things OpenStack, OpenShift, and infrastructure automation tools, such as Puppet and Chef, with FlexPod.

Pin It on Pinterest