Tivoli Provisioning Manager

From Wikipedia, the free encyclopedia
Jump to: navigation, search

Tivoli Provisioning Manager (TPM) is a product in IBM´s Tivoli Software brand. Its purpose is to automate the provisioning of virtual servers and software. TPM is a "manager of managers", in that it does not manage any hardware itself, but issues commands to the hypervisors that do actually manage the hardware. TPM can orchestrate the various tasks, and provide a common interface for different platforms, notably Intel-based managed by VMware to host MS-Windows and Linux virtual servers; and IBM's own AIX servers running on pSeries.

History[edit]

TPM originated with Think Dynamics which IBM acquired in 2003.[1] Their "Think Control" product was good in provisioning and managing (virtual) servers in data centers. IBM added their "OPAL" Integrated Service Management Library, and marketed their new product as "Tivoli Information Orchestrator" - hence the appearance of the letters "tio" in many product files of TPM.

While TIO appears to not have been a huge success, IBM spun off the deployment engine as a product of itself.

  • v4: combined with the aging "ITCM" desktop management suite, was marketed as "TPM for Software"
  • v5: general provisioning resources
  • there appears not to have been a v6
  • v7.1: integrated with the new Tivoli Process Automation Engine (Maximo) GUI. TPM was also incorporated into Tivoli Service Automation Manager.
  • v7.2: has many improvements; most notably, the workflows are no longer extracted from the DCM database and executed line by line, but are converted to Java and run from bytecode, which is much faster.

Working[edit]

Data Center Model[edit]

TPM works from an extensive Data Center Model that contains all server- and software-components, with their attributes and relations. As of v7.1, this is part of the Maximo database (maxdb71).

WorkFlows[edit]

All TPM's actions are executed by WorkFlows. These are written in a proprietary interpreted procedural scripting language. Most information must be drawn through queries from the DCM. Most string manipulation must be done by Jython calls - because both the WorkFlow interpreter and Jython parse, interpret, and manipulate these strings, great care must be taken in writing them. Actions on server systems are done through scriptlets, which generate (shell) scripts that are executed on the target servers.

Developing[edit]

For developing TPM workflows, one needs the so-called Automation Package Development Environment (APDE): this is the Eclipse Integrated Development Environment with a special TPM plugin. It needs to be configured to have access to the DCM database: all workflow code is stored by line in the database.

References[edit]

External links[edit]