Testing considerations when adding a device type
This section includes the following topics:
Troubleshoot device interactions by enabling Transcript Debugging (either in the individual job, or globally in the Admin > System Parameters page). This will add debug messages to the transcript that identifies the prompt and response matching that is performed during the communications. You can also turn up logging in your logging.properties file to see even more information (Editing logging properties for additional instructions on changing your logging settings). Add these lines and restart tomcat:
If it's not clear what's going on from the log file, then you can simply telnet or ssh into the device and manually execute the commands in question to verify the correctness of your interaction prompt/response sequences.
Several Admin > System Parameters relate to device communication (for example, any timing value that could depend on the performance of the customer's network/equipment). Consider tweaking them if you are having timing issues:
- Timeout for Establishing Connection
- Timeout for Re-Establishing Connection After a Reboot
- Timeout for Script File Transfers
- Timeout for Image File Transfers
Note that the image file transfer duration parameter should be used as a timeout in interactions involving image file transfer commands being executed. For text transfer commands, you should be able to rely on the default response timeout.
For some devices (for example, HP) which perform their file transfers silently in the background, you should also insert an appropriate pause using these values, to avoid trying to prematurely read the results of asynchronous file transfers.
The following global properties relate to device communication (covering any timing value that does not need to be a system parameter but which we might want to be able to tweak at site). Consider tweaking them if you are having timing issues:
Note that you may see various exceptions written to the log files referring to unexpected EOFs, interrupted reads, or even null pointer exceptions, which do not cause execution of the device action to fail. These are caused by the fact that the underlying java InputStream classes being used are running in their own threads to be able to support non-blocking reads. When the device action (for example, snapshot) completes and the connection is closed, this can cause these harmless exception messages when the InputStream threads are terminated as a side effect.
Use the GUI to perform an entire configuration copy cycle as follows:
Snapshot+mark-trusted, Deploy to Active-trusted-running, Commit, Deploy to Stored-trusted-startup, reboot. View the Discrepancy Summary Report (Reports > Priority Reports > Discrepancy Summary) for that device to ensure that there are no discrepancies. If there are discrepancies, you must go back and tweak the discrepancy-related Device Type tags, such as commentLines, then run a Refresh Device Status to make such changes take effect. The goal is to show no running versus startup discrepancies under normal circumstances.
Use the GUI to test whether you can receive syslog messages from the new device type as expected. Be sure to enable the Auto Archive policy. Telnet or ssh to the device from a system other than a BMC Network Automation system, make a configuration change, then log out. Check for the Auto Archive policy to trigger when a change is made; if it doesn't, you might need to add a new string to the “Log All Configuration Changes” canned external event filter.
Be sure to add syslog filter strings carefully. Use text that is unique to your device type to avoid collisions with your other devices (which may emit similar syslog messages that do not mean a configuration has changed).
Device import testing
Test whether you can successfully import the new device using a CSV file. For information about the CSV file import format, see Mapping for the CSV format.
Test whether you can successfully import the new device from HP Network Node Manager (NNM) as applicable.