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.