The problem I mentioned in version 1.0.46, wherein the bna://, OCI, and other protocols were reporting “unknown protocol: bna” or “unknown protocol: osmsql”. It seems that I had indeed butchered a search path, but it’s one burned into the main application.
Fixed now, should work fine 🙂
In this revision, minor changes were done to move the OnCommand and DCNM client code outside of the non-public source base and into the public source base at OSMURLConnection.java and DCNMURLConnection.java. This allows for external audit of the code and may improve trust and reduce concern. This is very similar to the work done in Revision 670 – BNA Client Migrated
As with Revision 670, the project retains all the test cases involving this and other parsers, so functionality is verified retained, there should be very little change in behavior. The DCNM backend-database client remains beta-quality and requires further testing if a user is willing; the OnCommand client has been heavily tested.
The OSM or OCI backend-database client was added 14 months ago (Revision 516 – Added parsing of OnCommand Data for Nicknames); DCNM backend-database client was added 13 months ago Revision 541 – Added parsing of DCNM Data for Nicknames). The OnCommand client was altered to append a fabric name for a specific environment 11 months ago (Revision 578 – NetApp msosmsql Pseudo-Protocol Adds Fabric Suffix) but can be used to show how easily the output can be transformed.
Expanded the option “-w” from Suggested Nicknames for Known WWN Patterns to vict.jar such that vict.jar -w 500a098300004060 shows “NetApp-4060-iGrp0-0N” giving suggested nicknames to NetApp Devices.
Just like Apparent VPLEX Patterns, this WWN Descriptor is empirically-based. Additional WWPN samples would help guide a better, more precise solution.
For a specific customer, I added a basic cut-n-paste customization of a different bnapsql:// or osmsql:// query that that appends the final character of the fabric nickname to the hostname and the WWPN such that hosts in “XX_FAB_A” or “XX_FAB_1” or “XX_FAB_a” become appended with “_A”; “_B”, “_2”, or “_b” become appended with “_B”. Anything else gets a “_X”.
This is done using a protocol “msosmsql”, for example:
java -jar vict.jar --nickname=msosmsql://server/
or
vict.bat -N msosmsql://server/
or since the customer has non-standard password (and the -n to store the result)
vict.bat -N msosmsql://user:pass@server/ -n A:\VirtualWisdomData\DeviceNickname\bna.csv
This allows a single query to produce nicknames on a different schema; also highlights a non-portability in the code that can be improved… but this is in production today. The customer’s response was “oh, that’s it? I thought that would be more difficult. How anti-climatic…” How can “easier than expected” be bad?
Fixed the access parameters for OnCommand Service Manager osmsql:// nickname source added in r516 and r525 based on Patrick’s info
In Revision 536, I implemented “–fixnicknamehistory” which applies any loaded nicknames (for example, those gained using OnCommand Extraction, those Parsed from Cisco Zones, or those extracted from BNA) to the underlying Portal Server database retroactively.
So long as the Portal Service is shut down, this can be done on a customer’s live server, but it’s more useful in analysis where nicknames arrived late yet the analyst cannot wait another week or so for nickname-ful summaries to be collected.
In revision 516, the basic capability to ask an OnCommand/NetApp management console for the Nickname/WWPN mapping has been added. This allows the reuse of the information it has collected by various device-specific methods to add meaning and facility to VirtualWisdom.
The ability to avoid re-polling and re-querying data essentially reduces the load to the devices polled and reduces the management effort: re-using the effort already expressed to configure one tool means that no additional effort is required — so long as the information is usable.
In this case, the same parser logic is used as was added for BNA in BNA Query later expanded to both “pools” in BNA. Like the BNA work, the OnCommand query simply reformats a query and sends it through the array of parsers to vote upon:
java -jar vict.jar --nickname=osmsql://user:pass@server:port/ --nicknameout=\VirtualWisdomData\DeviceNickname\nicknames.csv
Default user/pass are not accurate, so that still needs to be resolved. Like the BNA parser, this method hits the underlying database directly, so it needs (firewalls/filters) direct access to the server, and is vulnerable to schema changes.