Few specific changes in this release, but a couple of little ones:
Expanded the option “-w” from Suggested Nicknames for Known WWN Patterns to vict.jar such that vict.jar -w 2100000b08123450 shows “Axiom-12345-c0p0” giving suggested nicknames to (Oracle) Pillar Axiom (SLM). This WWN Descriptor is not very precise, but is empirically-based. Additional WWPN samples would help guide a better, more precise solution.
In revision 558, I added a logic to PHC that exercises the “-w” from Revision 555: VMax Nickname Suggestion back to Suggested Nicknames framework so that for missing nicknames, a phc-Nicknames.csv file attempts ot provide suggested nicknames for the WWNs of missing nicknames that it understands.
In short, PHC now provides suggestions for missing nicknames, making it possible to have nicknames for hosts the customer may not even be aware are visible by the VW Platform.
Where possible, PHC.jar avoids simple things such as forgetting to set the LinkNames-From-Nicknames setting in Views::Setup::FabricManagement.
Not running the PHC.jar both skips the FAE’s Deployment Checklist, and risks the issues that the PHC checks for.
In this case, the FAE didn’t run the PHC, didn’t set the LinkNames-from-Nicknames, and the links don’t reflect the NPIV names. This is a serious problem in Analysis which is why Stuart Bridger asked for this to be added.
The input to this filter is a list of links and names (the script itself includes a viwc.jar sample). The result is a filter which can be used to ignore the NPIV ports in ProbeSW.
Para 3.1 of the XML specification says that the order of attributes to an XML element is not significant; for example, the following two statements are equal:
<A left=”one” right=”two”/>
<A right=”two” left=”one”/>
Unfortunately, it seems we wrote our own parser, and missed that part. For what it’s worth, we’re probably using some sort of SAX which leverages the exactness of XML’s syntax markup, so there’s a certain portability and disambiguation there, but the VW parser gets confused when attributes to OUISignature are not in the order it understands.
Similarly unfortunately, I had to break the OUISignatureList writer to accommodate that. The risk is not that other XML parsers will not understand — they will, because they don’t care about ordering. The risk is that I’m building a basic “just print the text” writer, I might make an error such as URLEscaping output. In jumping on a leaky boat, I may also sink.
In the meantime, OUISignatures written by these tools are directly replaceable into VW’s config.
RemoteWisdom can now trigger a PHC run.
The sequence “Run PHC” is backed by RunPHC.seq which is now tracked as a sample method of running phc-xlsx.jar from inside RemoteWisdom Access Gateway, or RWAG, based on a click in the RemoteWisdom Enterprise portal.
I had a few customers who had no idea their backups were not running. Typically this is because of space-exhaustion, but sometimes this was because the backup schedule was not set, or it had become deactivated.
PHC on/after version 0.2-537 will now confirm that a backup was completed within 14 days; this value was chosen based on the recommendation that backups be done weekly, and the longest possible “staleness” of a backup is when the next backup is running: 7 days. Missing two backups is a critical concern. If a backup wasn’t scheduled, then there will be no backup logged; if a backup fails due to space, it will still be cause by not showing a completed backup. Either way, we can now catch when a portal service has no protective backup and is a risk to upgrading.
In this revision, I incorporate Welford-via-Knuth into the running statistical calculation, providing a running mean/deviation calculation to show where the greater portion of insertion delay are.
Why?
The “mean” of a value is nearly useless for planning: it’s just an average. An understanding of how that value varies can help get a better idea of it just as any ability to match the behaviour to a predictable curve. A mean+/-1deviation can give a basic idea; a mean+/-3deviation can show where generally “all the non-unusual ones” land. Put another way, mean+/-3deviation can tell where all the value land once the aberrant outlying points are removed.
Currently, this means that the summary calculation now shows the mean delay plus the mean+1deviation “ceiling”: a mean +/- deviation provides two values of course, but we only worry about the worst case when a risk exists of taking too long to insert a summary row.
PHC-0.2-536 showing mean+1deviation
Currently, I’m not sure whether the mean+1deviation is the more critical value than the reported mean, nor whether we should shift to the mean+3deviation as a more appropriate metric.
This revision reduces some clutter in that some checks that don’t apply — such as ProbeVM checks in a ProbeSW-only environment — are avoided. In that way, the content shown has higher signal-to-noise ratio.
Revision 529 is where the FileSystem Layout Detection (r527) is used to start highlighting risks in Summary Insertion Delay.
I would prefer to also look at the insertion time rather than delay, as delay may well remain constant while the actual insertion cost can lead to longer delay. That’s like addressing speed difference rather than distance between two race cars: looking at differences in speed can alert more quickly and predict changes in distance. Similarly, more metrics can be watched once I figure them out. Just like most users, I’m looking from the outside, but I can fake up the interpreted content in a known-ciphertext-attack -like method of using conditioned input to the parser to tell me what I’m seeing.