Create clustered LUN based on existing IGROUP name

[trentino123]

Dear Community,

Attached is a workflow that creates a clustered LUN/qtree and igroup/initiatiors and maps the lun, but requires no cluster name/ip or vserver/input. It does this by retrieving this information from an existing/zoned/mapped igroup name search( the igroup name will try to match a VMware cluster name which is part of the existing igroup name ). The reason for having a workflow with minimum inputs is to be able to call it from BAO ( so we only need initiatiors, size, server_name ( which will be the volume and qtree and also part of the new igroup created name ), and VMware_cluster name ( 4 INPUTS TOTAL ), without having BAO to tell WFA on which cluster/vserver it needs to create the LUN.

I am stuck at the end with the Map LUN command, the error is the following:

Found variable - expected literal
At command 'Map LUN', tab 'Lun', variable 'lun1'

Kindly advise.

Thanks in advance!

[shailaja]

Hi,

Could you please provide the DAR file to take a look at?

You could also look at the sample workflow shipped with the product "Create, map and protect Clustered Data ONTAP LUNs with SnapMirror" and the usage of the command "Map LUN" there.

In general, the Lun object is most probably already defined in your workflow and you could use the option "by using a previously defined Lun" when defining the parameters of the "Map Lun" command.

The input to that would be the name of the variable used in "Create Lun" command 

Thanks,

Shailaja

[trentino123]

Hi Shailaja,

Attaching the .dar in a .zip.

The lunmap command is configured the same as the certified workflow with snapmirror, but I am doing something wrong for sure.

Please advise.

Thanks in advance,

Luciano.

[shailaja]

Hi,

The issue is in "Other parameters" tab of "Map LUN" command instance used in the workflow.
LUN id parameter is of string type and should be defined accordingly.

It has been defined in the attached workflow as "lun1" which refers to the whole LUN object being created.
It should be changed to lUN Id used for mapping this specific LUN to the iGroup. This is same as the last value if you were using the command line:
f3270-208-238-239-240-241::> lun mapping create -vserver shails -path /vol/datavol1/lun1 -igroup igrp1 -lun-id 2

In the sample workflow, it is defined as shown in the screenshot. The sample workflows creates multiple luns using a loop and hence the LUN id is dynamically determined as shown

Now, the error message
"Found variable - expected literal" is actually referring to this issue.

However, I agree that the error message is mis-leading in its location part"
"At command 'Map LUN', tab 'Lun', variable 'lun1'"

The tab should have been "Other parameters"

An issue has been filed for the same. You could refer to #864894 in case of a support case.

The w

Thanks,
Shailaja

[trentino123]

Hi Shailaja,

Thanks for the quick response. I have tried before to add a number alone and also a 'quoted' number in the Other Parameters ( where the lun id ), without sucess. Same error.

Have even tried to add a random function that generates a random number ( JTrandomNumber(1023 ) ). Same error.

Will that be solved in case  #864894 ?

Thanks !

[shailaja]

Hi,

I actually did the change to the value provided to LunId parameter and was able to get a successful preview for your workflow.

The change done was as follows:


A screenshot of successful preview is:

Would you please try again or provide the DAR where you have made the modification to LunId parameter and still hitting the issue ?

Thanks,
Shailaja

[trentino123]

Hi Shailaja,

I am attaching the workflow with the LUN ID change on the LUNMAP command at your request.

Seeing the same isse. WFA version is 2.2.0.2.6.

Thanks in advance.

[shailaja]

Hi,

You are right. There was another place in the workflow where the issue is present. It is not about "lun1" variable, but in return parameters defined for the workflow.

Please refer to the image and change the value of the return parameter to "igroup1.portset.name" and try again.

Thanks,

Shailaja

[trentino123 · Accepted solution]

Thanks Shailaja ! That fixed the issue ( though it was related to the maplun command and foresaw the return parameters ).