Does anyone know if there is a good way to verify that a script is working correctly. I simply want to take a snapshot of a virtual volume on a daily basis, keep the snapped volume around for a few days and then delete it.
I know how to script it to get the virtual volumes created, and then to delete them, but it seems there is no way to confirm the virtual volume actuall has been created.
(This is from the HP manual.
Except where noted, the following codes are returned indicating success or failure for each individual
command:
• 0 indicates that the command was successful.
• 1 indicates that the command failed.
18 CLI Command Syntax and Conventions
Note that these exit status codes only indicate the execution status of the command itself. The results of individual CLI commands should be determined from the command output. For example, if you issue the addsnmpmgr command with an invalid IP address, the command output returns Invalid IP address and an SNMP manager is not added; however, the exit status is 0 (successful)
because the command itself was successfully executed, even though the intended result of the
command (adding an SNMP manager) was not achieved.)
It either returns an exit code of 0 if the script runs or a 1 if it does not run.
For example: Say I wanted to take a snap of a lun called lun 1. It I snap it I can create a file named lun1.daily. If i run the same script again it will attempt to create another lun1.daily which is not allowed (it will generate an error), however the script thinks it worked properly, because it's not smart enough to return a failure code. Of course I know I plan on running the create snap script once a day, so it should not duplicate the Virtual Volume name. I use this line in my code
cli createsv -ro @vvname@.@a@.nightly
Which will create a file name which is vvname.mon(dayofweek).nightly. How can I really confirm that the file is created each time.
Let me know if this does not make any sense.
Script Error Checking
Re: Script Error Checking
You have found the big hole in the CLI for scripting. I have suggested to 3par several times they need to fix that so that the CLI should not return a 0 unless the command executed as called. My guess is they have no intention of fixing this as they would prefer we use the web API. I would guess most admins can cobble together scripts, but very few could write a web app.
The only way to catch it is to run additional commands that that generate output of the command you ran to see that what is there is what you expected. You woudl have to run some command to do a showvv passing the volume name you expected to be created and then read that output to find that it is there. This is a huge hassle and we do it for essential operations that my scripts need to verify. There are some commands we just go with the assumption they will work, which is not good.
There are some CLI commands that actually do return failure if the command syntax was correct, but the command did not execute as specified. I also complained that sets up a very inconsistent pattern. To me the CLI needs work and should not be abandoned as a scripting tool, but it seems for scripting they are pushing people to the web API which they say will be consistent. Another issue you will find is the output of some commands wil change from version to version thus an OS upgrade may break your scripts.
The only way to catch it is to run additional commands that that generate output of the command you ran to see that what is there is what you expected. You woudl have to run some command to do a showvv passing the volume name you expected to be created and then read that output to find that it is there. This is a huge hassle and we do it for essential operations that my scripts need to verify. There are some commands we just go with the assumption they will work, which is not good.
There are some CLI commands that actually do return failure if the command syntax was correct, but the command did not execute as specified. I also complained that sets up a very inconsistent pattern. To me the CLI needs work and should not be abandoned as a scripting tool, but it seems for scripting they are pushing people to the web API which they say will be consistent. Another issue you will find is the output of some commands wil change from version to version thus an OS upgrade may break your scripts.
Re: Script Error Checking
Thanks for the reply. I was looking into the showvv as a way around the issue, but I'm just not sure how to get the expected output I wanted. I tried to see if I could pass the output to a text file but it appears it won't allow me to do that either.
Re: Script Error Checking
I have a scrip that generates the snapshot name based on the VOLID of the base volume then a character string that represents the unique date/time. That unique portion string is generated at the beginning of the script execution so it is consistent across all snaps.
Example,
script starts and I generate unique sting 20140221-11503222 which represents YYYYMMDD-HHMMSSmm Then for each volume I get the base volume ID number and create snapshot names as such
VC-VOLID-"unique string"
If you do that you can predict what the snapshot name would be and then use showvv to pass it that volume name and scrub the results to make sure the volume is there. I will tell you that I do not validate that snaps are created, the array would have to be out of snap space to fail on a snap generally and if that happen I would get alerts from the array that the CPG can not be written to. Sure there can be a network issue or something, but my assumption is if the snap command did not return a 1 then the snap was good. I do output scrubbing more for remote copy tasks to determine age and state of replicating volumes, but I know that in 3.1.3 the output will change and am bracing for scrip re-writes.
The other advantage of controlling the name format is I have date/time in there so just looking at snap names I can tell what date/time the snap was taken ratehr than pulling the creation time form the IMC or CLI.
Example,
script starts and I generate unique sting 20140221-11503222 which represents YYYYMMDD-HHMMSSmm Then for each volume I get the base volume ID number and create snapshot names as such
VC-VOLID-"unique string"
If you do that you can predict what the snapshot name would be and then use showvv to pass it that volume name and scrub the results to make sure the volume is there. I will tell you that I do not validate that snaps are created, the array would have to be out of snap space to fail on a snap generally and if that happen I would get alerts from the array that the CPG can not be written to. Sure there can be a network issue or something, but my assumption is if the snap command did not return a 1 then the snap was good. I do output scrubbing more for remote copy tasks to determine age and state of replicating volumes, but I know that in 3.1.3 the output will change and am bracing for scrip re-writes.
The other advantage of controlling the name format is I have date/time in there so just looking at snap names I can tell what date/time the snap was taken ratehr than pulling the creation time form the IMC or CLI.