ATOS - ADDM TKUs On Steroids

Version 1
    Share This:



    Due to the increasing demands for custom application mappings within our company, it became necessary to have a set of tools to generate our custom knowledge update files and to deploy them. This here covers the second of those tools. The general idea is to be able to upload the TKUs in parallel on all ADDM appliances within a specified ADDM instance (DEV, TEST, etc). In addition, we wanted tools that can be operated from a windows desktop, hence the choice of Powershell. The REST API available since ADDM 11.1 made it possible to develop this tool.





    Users working with the ATOS tool must be granted the api-access group in ADDM.



    Some Notes on the Powershell Code


    The provided code does not run as-is. There are a number of variables that must be modified in the code to reflect the environment in which ATOS is supposed to be run. It has been implemented for our specific needs consisting of multiple environments, each containing multiple ADDM appliances, none of which in cluster mode.


    • We have four different ADDM instances we call RTEs (run-time environments): PROD, AT, UT, SAND. This is reflected by the powershell variables [array] $PROD_HOSTS, [array] $AT_HOSTS, [array] $UT_HOSTS, [array] $SAND_HOST and $host_shash. You can modify the names, add more if you have more RTEs or remove the RTEs you don't need.
    • Next we have the standard BMC TKU, the EDP TKU and our CUSTOM TKU. Hence the $tku_shash (synchronized hash) has got tku, edp and custom hash keys. You will need to modify these according to your own requirements.
    • We use LDAP authentication for accessing the ADDM GUI, thus a LDAP module is provided to get a valid OAuth2.0 token for further processing. Check the variables $ldap_host, $ldap_port, $ldap_user, $ldap_pwd, $ldap_basedn in the powershell module $ATOSDIR\ATOS scripts\custom-ldap.ps1. For other authentications, you will need to implement your own module.
    • We use the same credentials in all ADDM RTEs, which simplifies all REST API calls, the OAuth2.0 token needs to be fetched only once. If you have multiple credentials on different ADDM appliances, you will have to modify some parts of the code.
    • The feature provided by the checkbox "Auto Cleanup Obsolete CUS" is experimental. The way we have implemented our CUSTOM modules is that the latest CUSTOM TKU contains exactly all modules implementing our own SIs and BAIs. We delete all CUSTOM modules from the appliance that are not part of the latest CUSTOM TKU. For instance we may rename the name of a module to something else. In this case, the module provided in the currently deployed CUSTOM TKU shall be deleted from the appliance, retaining only the module with its new name provided with the latest CUSTOM TKU. Unfortunately, this feature is not yet available via a REST API endpoint. The current implementation uses the tw_pattern_management CLI tool over SSH, which is far from optimal. In fact, it does not work for some subdomains due to firewall limitations. Like I said, it is experimental and I plan to update the code as soon as the Communities idea REST API new endpoint to deactivate/remove inactive pattern modules is implemented. You may want to vote for it!
      The global variables
      $pm_shash, $sshkeys_shash and the function cleanup_obsolete_custom_modules as well as the $ATOSDIR\ATOS SSH\tideway-key.{prod|at|ut|sand} SSH keys can be ignored when you don't use this feature.



    Using ATOS


    The ATOS GUI open up when the main Powershell script ATOS.ps1 is run. The parameters can be provided in any order as soon as the GUI elements are enabled. The order detailed below is only a suggested one, filling up things from left to right and from top to bottom. Most choices can be made via menus or buttons. In the ATOS GUI, TKU stands for the standard BMC TKU.


    ATOS will remember the discovery status and reset it to what it was before the rollout of knowledge uploads.


    Using ATOS is at your own risk. We have successfully used it for about 1.5 years. The most obvious bugs have been fixed and the options provided by the checkboxes have been added. There are probably some glitches in the GUI, in particular the RESET button implementation has not been toroughly tested.



    I start by selecting the RTE (run-time environment). The default is SAND, hence the SANDbox  systems are displayed when you start ATOS. Let's select RTE = UT.



    The Appliance List is updated to show the hostnames belonging to the selected RTE. Next I provide my credentials, which are the credentials I use on the ADDM GUI. Remember you must be granted the api-access group in ADDM.



    When the credentials are verified, the current versions of the TKUs are fetched on the appliances and displayed in the Appliance List GUI element. You can now select the TKUs to roll-out.



    There are some limitations in this implementation:

    • TKU and EDP must have the same version.
    • TKU and EDP cannot be rolled out separately.
    • CUSTOM can be rolled out separately.


    In other words, you can deploy the following sets:

    • TKU and EDP and CUSTOM.
    • TKU and EDP.
    • CUSTOM.


    When you deploy the BMC TKU, the "Allow Application Restart"  checkbox gets enabled and you can select it. In fact this is highly recommended to do so. This feature has been introduced in the API version 1.1. If the BMC TKU requires a restart, and if you do not select the option, the upload will fail. See the Communities thread fails with REST API upload .



    The "Auto Cleanup Obsolete CUS" checkbox can be selected optionaly. Remember this is an experimental feature for CUSTOM modules only in the sense described above that comes with severe limitations, see the relevant section above.


    The way I am using it is to deploy the TKU and EDP separately, once a month. We are always quite up-to-date regarding BMC knowledge updates. If I have to deploy a new CUSTOM TKU at the same time, then I do it separately and I enable that option. Typically we deploy several CUSTOM TKUs per month so that option is quite useful for us.  But its usage is tailored for our specific needs, you may have different usages in your own environment. The code is here to be used and improved upon, or ignored if you don't need the feature.


    In this example we are going to deploy the TKU end EDP knowledge updates. You can now press the START UPLOAD button.



    A summary of the knowledge uploads about to be deployed on the appliances is displayed. This is the last place to back out. When you press Yes, there is no longer any possibility to interrupt the process.



    You see that at this moment it is uploading the TKU on the first box wheras it is already uploading the EDP on the second box. The Current TKU column for the second box reflects the new TKU.