I discussed adding NetApp roles and making them available in this post.  If you haven’t read that one, please take a moment to read it as it covers the installation and configuration settings to make these roles usable.

Much like the Cluster Config role allowed for easy cluster setup from a single variable file, so does the Vserver Create role.

The same playbook can be used as was used with Cluster Config to do both roles with only a minor change.

---
- hosts: localhost
  gather_facts: no
  vars_prompt:
    - name: admin_user_name
      prompt: domain admin (enter if skipped)
    - name: admin_password
      prompt: domain admin password (enter if skipped)
  vars:
    input: &input
      hostname: "{{ netapp_hostname }}"
      username: "{{ netapp_username }}"
      password: "{{ netapp_password }}"
  vars_files:
    - globals.yml
  tasks:
  - name: Get Ontapi version
   na_ontap_gather_facts:
      state: info
      <<: *input
      https: true
      ontapi: 32
      validate_certs: false
  - import_role:
      name: na_ontap_cluster_config
    vars:
      <<: *input
  - import_role:
      name: na_ontap_vserver_create
    vars:
      <<: *input
    when: vservers != None

The changes are adding the variable prompts for an AD admin user and password.  These are filled out, via the prompts or as variables in the globals file, if a CIFS vserver is being created and will be joining a Windows domain. The addition of the second role call for the Vserver Create role has an extra line `when: vservers != None`. This line will only run the Vserver Create role if the globals file has Vserver defined.  That way you can have one master playbook even if you aren’t planning on using all the roles defined each time.

The options to set for Vserver Create are as follows.

---
cluster: <short ONTAP name of cluster>
hostname: <ONTAP mgmt ip or fqdn>
username: <ONTAP admin account>
password: <ONTAP admin account password>

Based on if Variables != or == None determines if a section runs.  Each variable will take one or 
more dictionary entries. Simply omit sections that you don't want to run.  The following would run 
all sections

vservers: # Vservers to create
  - { name: nfs_vserver, aggr: aggr1, protocol: nfs } # protocols determine what additional steps 
are done.  
Protocols can be combined to create multi protocol vservers.
  - { name: cifs_vserver, aggr: aggr1, protocol: cifs }

vserver_dns: # DNS at the Vserver level.
  - { vserver: cifs_vserver, dns_domains: lab.local, dns_nameservers: 172.32.0.40 }

lifs: # interfaces for the Vservers being created
  - { name: nfs_vserver_data_lif, vserver: nfs_vserver, node: cluster-01, port: e0c, protocol: nfs, 
address: 172.32.0.193, netmask: 255.255.255.0 }
  - { name: cifs_vserver_data_lif, vserver: nfs_vserver, node: cluster-01, port: e0c, protocol: nfs, 
address: 172.32.0.194, netmask: 255.255.255.0 }

cifs: # Vservers to join to an AD Domain
  - { vserver: cifs_vserver, cifs_server_name: netapp1, domain: ansible.local, force: true }

fcp: # sets FCP ports as Target
  - { adapter: 0e, node: cluster-01 }

This makes it very easy to add Vservers or Data LIFs to existing Vservers and keeps all the documentation in a single file.

Roles for NAS and SAN volumes (shares, exports, LUNs) and a role for creating a SnapMirror relationship including verifying peer settings are coming soon.

As always, if you aren’t already on our Slack Workspace you should join at https://www.netapp.io/slack.  Join me and other developers for Ansible in the #configurationmgmt channel.  Also be sure to check out the other sections on www.netapp.iofor information on all our Open Ecosystem projects including OpenStack and Containers.

David Blackwell on Linkedin
David Blackwell
Technical Marketing Engineer at NetApp
David is a twenty year IT veteran who has been an admin for just about every aspect of a DataCenter at one time or another. When not working, or tinkering with new software at home, David spends most of his free with his four year old son and his lovely wife.

Pin It on Pinterest