With Red Hat Summit fast approaching let’s take a look at a pair of roles today.

In previous posts I have covered day-0 operations with the Cluster Config role, and day-1 operations with the Vserver Create role.  Now I will cover the repeated task of creating new storage provisions for end users with two new roles, NAS Create and SAN Create.

To understand the roles first let us look at a playbook to call the roles.

- hosts: localhost
  gather_facts: no
    input: &input
      hostname: "{{ netapp_hostname }}"
      username: "{{ netapp_username }}"
      password: "{{ netapp_password }}"
    file: globals.yml
    - "{{ file }}"
  - name: Get Ontapi version
      state: info
      <<: *input
      https: true
      ontapi: 32
      validate_certs: false
  - import_role:
      name: na_ontap_nas_create
      <<: *input
    when: nas != None
  - import_role:
      name: na_ontap_san_create
      <<: *input
    when: luns != None

Like the other roles described in my previous posts these also use a variable file that is read in.

For NAS, the variable file contents look like this:

  - { name: nfs_share, protocol: nfs, vserver: nfs_vserver, client:, ro: sys, 
rw: sys, su: sys, aggr: aggr1, size: 10 }

These sections are

Name: name of the volume, which is also its junction path /name
Protocol: If this is to be NFS or CIFS that information goes here, and the role will know which steps to run.
Vserver: The name of the vserver that will host the volume
Client: for NFS exports, this is the IP address or CIDR of the host or subset that has access to this export.
Ro: for NFS exports, this defines the Read-Only access
Rw: for NFS exports, this defines the Read-Write access
Su: for NFS exports, this defines the Super user access
Aggr: the name of the aggregate for the volume to be created on
Size: the size in gigabytes of the volume
Share: for CIFS shares the name of the share export

If you are a creating CIFS share you can omit all the NFS export specific options and the same applies if you are creating an NFS export, like in the example, you can omit the share: option.

SAN has a different set of option lines in the variable file:

  - { name: igroup1, vserver: san_vserver, group_type: iscsi, ostype: linux, initiator: 
“<iqn or wwpn>” } # the quotes for iqn/wwpn are necessary because of the : in them.
 - { name: lun1, vol_name: lun_vol, vserver: san_vserver, size: 10, ostype: linux, 
space_reserve: false, igroup: igroup1 }

Igroup sections:

Name: name of the igroup to be created or used
Vserver: the name of the vserver that will have this igroup
Group_type: specify iSCSI or FCP igroup type
Ostype: type of OS that will attached with this igroup
Initiator: IQN or WWPN of host access.

Luns sections:

Name: name of the LUN to create
Vol_name: name of the volume the lun will be in or will be created
Vserver: vserver to host lun
Size: size in GBs of the lun
Ostype: type of OS that will attach to this LUN
Space_reserve: if true create LUN thick.  If false, create LUN thin.
Igroup: igroup to map lun in.

Ansible allows for easy automation by supporting calling a playbook via the command line and passing in variables that fill in the user defined items.  The same concept can be done with these roles.

You may have noticed a variable in the playbook called ‘file’.  This allows me to call any configuration file from the command line, like this.

ansible-playbook playbook.yml --extra-vars “file=/path/to/my/yml.yml”

In this example, the yml.yml file contains the NAS or SAN entries defined above depending on which type of resource you want to create.

I have a session at Red Hat Summit that will be all about these roles plus a surprise fifth role.  If you are there, please come check it out Wednesday 4:45pm, see some cool demos, and get your questions answered live.

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.io for 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.