2012-10-04 02:35 PM
I'm running into an issue with the Resize Volume command. At a high level, it has 3 mandatory parameters and it's complaining that it's only receiving 2 - the one missing is the TargetSize. I'm at a loss at this point for why this variable isn't getting passed since I am inputting it and the user inputs report the value. I do have this user input classified as a number. I suspect I'm missing something rather obvious but I just don't see it yet.
Here are some screenshots with the Find Chart first:
And now the user inputs tab from the Planning Failed window:
Looking at the code for the command I know that size_mb tracks back to TargetSize which is the parameter WFA is complaining about not being there. Yet as you can see from the second screenshot I am inputting a number that I see as acceptable. Any insight is much appreciated, thanks!
Solved! SEE THE SOLUTION
2012-10-04 04:04 PM
A quick question (Something I might not getting since its nearing 0100) - You are trying to find a volume (Into volname).
and if you do you return.
If volname is not "found" (And the variable not populated), you search for an aggregate and define a new variable just for the sizing
(A small quirk of WFA in that resize command) and refer to volname (Which should have nothing, since it was not found).
What am I missing?
I see that you put in the right value in size_mb, but I suspect the issue here is something else and an incorrect error message appears.
Would be happy if you can upload an export of it.
Here's an example of using "Resize Vol" only if aggregate size permits
(Not sure if would help but perhaps something would pop up.
2012-10-05 09:51 AM
Yes, I am trying to first confirm the named volume to resize actually exists. Then I confirm that the aggregate that contains this volume has enough space to accommodate the size increase requested while still remaining under a maximum utilization percentage.
I will take a look at the example you uploaded, thanks!
2012-10-05 10:42 AM
Ah I see now, I remove the first column (or made it unviewable and ignored it). I guess I don't understand why the Resize Volume command has 2 columns, one for new volume and one for volume. In my mind, I'm simply resizing an existing volume so why do I need 2 columns of activity? I'll update the first column with the same FindChart and see if that works.
2012-10-05 11:24 AM
Okay, this is driving me mad (well, not really). I'll create a find chart under the New Volume column, save it and then when I go back to edit it it's gone! But wait, it's not actually gone it now exists under the Volume column ?!?!?! I don't understand this at all, why would the find chart move to a different column when i specifically edited the first column?
Yet in your example both columns are using the same find chart. I think this may be why I removed the original column...
2012-10-05 01:46 PM
Quick explanation (I already highlighted it once in the community - https://communities.netapp.com/message/65618#65618):
Resize vol command has 2 paramteres (nit counting the enabler):
1) Volume - The actual volume we will resize
2) NewVolume - Volume object that includes data to resize (New size, new Max auto increment, new Increment, new snap reservation)
We take what's there in NewVolume and apply it on Volume.
If you find a volume that's existing - Search for Volume and make sure it was found.
2012-10-05 01:52 PM
A word regarding Find Charts:
Find charts define variables. They can define all the variables in one find charts.
There's a very loose correlation between the definition of variables and find charts.
The way it works:
When you have a command "Create Volume". We go over the parameters (Enable + Volume) and evaluate them one by one.
First the enabler (Let's presume it's "true") and then the Volume. The volume is a variable called "newVol" so we search for the
find chart that house a define node or find node for "newVol" and we execute it.
If that find chart happens to define other variables, it would save us further evaluation when we'll come up with them.
A WFA variable can get one value and cannot be re-assigned during the flow (Barring repeat rows obviously, let's put this to the side).
So, for a workflow that creates a volume, and qtree and a cifs share - You can either use 3 find charts,
or just one housing 3 define nodes. Evaluation wise it is different, but the end result is the same.
Hope that helps... :-)
2012-10-05 02:05 PM
This does help - I think I was initially getting confused around why the TargetSize parameter is mapped to a different object name (and all the others). This does make sense and allows for breaking down the flow into smaller chunks if desired. I am however getting confused as to why my variable doesn't seem to remain attached to the find chart I create for it. The find chart still exists but the NewVolume variable doesn't pull it up after I create it (clicking on the variable brings up a new FindChart template right after I saved the one I created).
Shoot, never mind, I just realized why - I was using different variable names in the variable field vs. the field in the spreadsheet. Okay, now I think I'm good. Whew!
2012-10-05 02:10 PM
here's hoping.... :-)
Do use our Auto-Complete feature extensively. Make sure you use the same names and it makes it easy on you.
Just press the down arrow and type to narrow down selection...
2012-10-05 03:56 PM
Oh yeah, I really like the auto-complete feature and make heavy use of it.
I did finally get this flow working and as expected, the troubles I was having were due to mistakes on my part. Incidentally, our UI takes the resize request in the form of usable MB but the Resize Volume command doesn't inherently adjust for a given snap reserve. In case it's useful to anyone else, here's the formula I'm using to account for that in the Define node for size_mb:
($NewUsable * ((new_size.snapshot_reserved_percent / 100) + 1.05))
NewUsable is the new usable size of the volume that the user wants to see.
new_size is the variable from the finder that determines if the volume named actually exists.
Thanks for your help!