Hey, Wow, I hadn’t bumped the internal version-check to 3.7.0.
So that’s done, and the PHC should no longer worry about the latest VW3 release when sanity-checking an environment.
Monthly Archives: September 2014
Version 1.0.52 – Parser Protocols Finally Fixed
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 🙂
JSON Hierarchy
Reply
The Entity Hierarchy for VW4 seems to look like this (still being confirmed)
wpg_div_wp_graphviz_1
Version 1.0.51- SubstituteWithSNICK fixed
I fixed a NullException in the -S function to vict.jar
The -S (Substitute with SNICKs) is similar to the -f (filterOut) as follows:
FilterOut (-f) removes all nicknames that are “predictable” or “provided” in VW3, and most likely provided by the VW3.x system to take the place of empty nicknames. Recall that VW3 will show an alias if available, an FCID is there’s no nickname, or a WWPN if no FCID is granted to a FLOGI. This means nicknamed devices show nicknames, but F-ports lacking nicknames show FCIDs, and ISLs (wherein no FCID is available) show WWPNs of the remote switch. FilterOut removes those predictable values, so that only the nicknames not appearing to be WWPN, the name “nickname (ISL)”, nor FCIDs (5-digit and 6-digit) are given. It can reproduce the original imported nicknames.
The risk, of course, is that bogus nicknames can be artificially elevated in status. The “provided” nicknames are overwritten by VW3 as new ones are available. A WWPN re-FLOGIs and gets a new FCID, that redefines the FCID-based nickname. The VW3 system will not overwrite a user-provided nickname, however.
What happens when the user imports a FCID-based nickname? The VW3 system will not overwrite it, so the wrong FCID is shown instead of the correct one. There’s no strong indication that this is occurring: VW3 doesn’t track whether a nickname is being conveyed or generated/provided. Additionally, “use Key Aliases” turns off ALL aliases, treating VW3-provided nicknames like user-provided nicknames.
FilterOut avoids this, and it’s as simple as using after a -nickname= collection:
VICT.BAT -N bna://bna.example.com/ -f -n nicknames.csv
java -jar vict.jar -N bna://bna.example.com/ -f -n nicknames.csv
SubstituteWithSNICKs (-S) takes this one more step:
- filter it out
- if there is a SuggestedNickname (SNICK) (see http://github.com/chickenandpork/wwndesc/), replace it with that
This allows the user to remove all FCID nicknames and replace them. Storage devices, SVCs, even some NPIVs (hey, vConnect and UCS, I’m looking at you) can be swapped in, identifying, for example, the Chassis (002a6a) of a UCS.
it’s just as simple as FilterOut:
VICT.BAT -N bna://bna.example.com/ -S -n nicknames.csv
java -jar vict.jar -N bna://bna.example.com/ -S -n nicknames.csv
or, verbosely:
VICT.BAT --nickname=bna://bna.example.com/ --suggestednicks --nicknameout=nicknames.csv
java -jar vict.jar --nickname=bna://bna.example.com/ --suggestednicks --nicknameout=nicknames.csv
Version 1.0.47 – Withstand Bogus Preamble While Parsing Zones
The consistent recommendation in examples and blog posts to collect zone information for nicknames looks like this:
plink.exe -l username -pw password IP.IP.IP.IP zoneshow > IP.IP.IP.IP.zoneshow
For example:
plink.exe -l scott -pw tiger 192.168.1.1 zoneshow > 192.168.1.1.zoneshow
Despite this, users still feel that “grabbing the log from putty is good enough”. That actually costs additional work, and mores, it means that greater-than-zero work is needed, and that seems to be a task that is fairly complex to do onsite with a customer when you’re jet lagged, and grumpy, and got zero sleep because the (m)hotel you slept in at company expense policy was beside a railway track for efficiency. I mean, c’mon, we all know that the best TV remote-control is the one with only one button, why can’t nicknames be that easy? Although it bugs me that directions cannot be followed, it bugs me even more that I need to be so precise. Why can’t I just skip the same stuff I skip manually?
So I did that: fibrechannel-parsers added the ability to skip any preamble that ends in “alishow” or “zoneshow” in order to accept the zoning text commonly offered for nicknames.
In order to confirm that an earlier release is never used if found during discovery, a testcase was added to vitools to confirm that the fcparsers jar includes the new handling of putty-dump-ish preamble that apparently occurs even when directions are perfectly followed and “collect zone or alias information non-interactively and no-never-ever use putty” is the rule that gets missed. vict.jar and vw4tool.bat should both be a bit more tolerant.
Version 1.0.46 – Check for Driver Availability During Build
In trying to catch more errors during build rather than runtime — i.e. even before the test cases are run — I’ve extended the behavior of “vict.jar –check” to check its own driver configs and to test-load the various handlers.
I’m still plagued by an error in bringing a driver online for nicknames. In this example, a customer — A CUSTOMER! Augh! — found the error “unknown protocol: bna”. A CUSTOMER found this! Crapola. So I went looking, and still chasing this one, but I know for certain that the drivers are all checked and present during build, and that they can be loaded. It’s somewhere else in the search process.