Revision 602 – Split and Build with external Parsers, Solved a Parse issue

In this revision, the parsing code is now external; it has been split out to “fcparsers.jar” from fcparsers-java rpm visible at github.com/chickenandpork/fibrechannel-parsers/ … this was done to improve code visibility and to allow bug reports to be created more closely to the specific piece of code involved.

In doing so, I also chased down a parsing issue in that the following block would produce a nickname short:

alias: NASMany_654321
                10:00:00:00:c9:44:44:10; 10:00:00:00:c9:44:44:11
                10:00:00:00:c9:44:44:20; 10:00:00:00:c9:44:44:21
                10:00:00:00:c9:44:44:30; 10:00:00:00:c9:44:44:31

Results:

10:00:00:00:c9:44:44:11,"NASMany_654321"
10:00:00:00:c9:44:44:20,"NASMany_654321"
10:00:00:00:c9:44:44:21,"NASMany_654321"
10:00:00:00:c9:44:44:30,"NASMany_654321"
10:00:00:00:c9:44:44:31,"NASMany_654321"

… clearly missing “10:00:00:00:c9:44:44:10” (and yes, per the weak consuming parser to which we send this result, no space can be between the WWN and the alias).

That was resolved by fixing the byacc parser code. All six members now show up.

Revision 600 – (weak) Suggested Nicknames for Apparent NetApp WWN Patterns

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.

Revision 599 – (weak) Suggested Nicknames for Apparent VPLEX WWN Patterns

Expanded the option “-w” from Suggested Nicknames for Known WWN Patterns to vict.jar such that vict.jar -w 50001442607a3b00 shows “VPlex-07a3b-A0-FC00” giving suggested nicknames to EMC VPLEX devices similar to the output of the CLI command ls -l /engine/**/ports.

This WWN Descriptor is not very precise, but is empirically-based. Additional WWPN samples would help guide a better, more precise solution.

Revision 597 – Zone-Voting Accepts Dupes by Default

Based on some work I was doing with JP “Skwerl” C, I found/remembered/was-embarassed-by Zone-voting ignoring possibilities of duplicate aliases as a default behavior.

This might have been cool before, but it’s out of fashion now. In fact, I find so many customers duping their nicknames, I wonder if there’s some advice on the ‘net suggesting it’s a good practice. Understandably, these are labels being extracted from zone names, so I cannot claim to be the ivory tower of accuracy or best-practice.

Inspection-worthy units have a more difficult time passing combat.

In this revision, I converted ZoneVote to default to allowing dupes; highlights some mismatched assumptions in test cases. see also “Zone Vote is only an approximation” 🙂