f5.multi_device.trust_domain.py does not account for many TMOS device state error

[jgruber]

There are several TMOS states which must be checked before adding a device trusted peer.

• Each peer device must have a unique device name
• MCP must be in a running state before you attempt to add a peer

The use of an iApp creates others opportunities for failures which show no details. Since adding a trust peer is an async process on a BIG-IP can can take a variable amount of time, there are OFTEN timeouts between an iApps implementation calling through TMSH and TMOS response. This will cause a timeout between TMOS and iApps which will propagate in valid information to the process. The process of adding a trust peer might have completed just fine, only the client is reporting an Exception.

Suggestion is to look at running individual TMSH commands through REST and providing some intelligence in the TrustDomain calls (It's already a manager class) which handles obvious timing errors and state problems with TMOS remote orchestration. Reference f5_onboarding classes if you want an implementation that has been tested as reliable.

[zancas]

This seems like @pjbreaux 's bailiwick to me.