The teamforge.py Script

Use the teamforge.py script to deploy and undeploy services, start and stop services, verify the status of services, verify the application environment, bootstrap or migrate data, back up and restore data and do much more.

Overview

Use the teamforge script wherever applicable as it subsumes the functions of the following legacy TeamForge scripts:

bootstrap-data.sh

bootstrap-data.py

bootstrap-reporting-data.sh

bootstrap-reporting-data.py

create-runtime.py

collabnet

migrate.py

post-install.py

snapshot.py

Starting from TeamForge 17.8, /opt/collabnet/teamforge/bin/teamforge has been linked to /usr/bin. You can simply run the teamforge command from any path.

Run the teamforge script as follows:

teamforge [command][-s serviceName] [other parameters]

For example, the following command displays the status of all the services:

teamforge status

TeamForge components and services

Components

TeamForge comprises of a set of components such as ctfcore, subversion, james, and so on. Some components are always required to be installed, while others are optional. By spreading these components over multiple RPMs, we make sure that users do not have to install everything all the time. Though this is valuable, RPMs alone prove insufficient to manage the components and their inter-dependencies.

Some components do not have a physical representation but are configuration-only.

RPM dependencies are restricted to the local machine only; however, in a distributed installation, dependencies between components must be tracked across servers.

In addition to the physical componentization (using RPMs), there is also a need for a logical componentization of TeamForge.

Services

Services represent a logical component of TeamForge. Such a logical component may either be a feature, which the user explicitly opts to install (for example, CVS) or a technical component (for example, Apache and Logrotate), which other services depend on. Services come with additional metadata which makes it possible to track and manage dependencies to a more fine-grained level.

Deployment dependencies specify which other services need to be deployed locally.

Provided Endpoints specify which network endpoints the service offers.

Required Endpoints specify which network endpoints the service depends on.

As such services are more fine-grained than RPMs and it is common to have a single RPM containing multiple services.

Service life cycle

A service can be in one of the following states:

Uninstalled: A service is uninstalled if the RPM that contains it is not installed. Uninstalled services do not exist as far as TeamForge is concerned.

Undeployed`: The RPM containing the service is installed, but the service has not been deployed yet. Deployment is also referred to as “creating the runtime”, but is specific to one service.

Dependencies unavailable: The service itself might be available, but at least one of its deployment dependencies is not in “Available” state.

Available: Service is fully functional.

Services that manage data have the following additional states:

Not bootstrapped: Data structures have not been initialized yet.

Not migrated: Data structures are initialized, but data needs to be migrated.

Services that have a daemon have the following additional states:

Dependencies unavailable: The service itself might be available, but at least one of its deployment dependencies is not in “Available” state.

Ports Blocked: The service is impeded from starting up because at least one of the ports it needs is in use by a different process.

Stopped: Service is an auto start-type service, yet is stopped.

Inactive: Service is a demand start-type service and is stopped.

Starting: Service is in the process of starting up.

Available: Service is running and healthy according to its health check.

Unhealthy: Service is running but unhealthy according to its health check.

Dead: Service is supposed to be running, but the process disappeared.

Doomed: Service is technically running, but it will never work properly because some part of it failed to initialize properly.

Stopping: Service is in the process of stopping.

Parameters

teamforge.py script accepts the following command line parameters:

[-s | --service]

Use the -s parameter to selectively act on a specific service or component such as selectively start, stop, bootstrap, backup and restore a specific service. For example, the following command gets you the status of Jboss:

/opt/collabnet/teamforge/bin/teamforge status -s jboss

[-f | --site_options_file]

Use the -f parameter to pass the
site-options.conf file's path as a command line
parameter (default is
/opt/collabnet/teamforge/etc/site-options.conf).

[--skip-verification]

Pass this parameter if you want to skip environment verification.

[-y | --yes]

Pass this parameter if you want to skip confirmation prompts.

[-p | --path]

The path to the backup or restore directory. Used with the teamforge backup and teamforge restore commands.</dd>
</dl>

Commands

The teamforge script can perform the following actions:

status

Show status of all services. Use the -s parameter to know the status of a specific service.

bootstrap

Bootstrap data (re-create data structures). Use the -s parameter to selectively bootstrap a specific component. Suppose, you did not have SVN on your TeamForge site and if you add SVN while upgrading to TeamForge 16.10 or later. You can now selectively bootstrap SVN alone.

Back up and Restore TeamForge Data Using the teamforge.py Script

Use the teamforge.py script’s backup and restore commands to back up and restore TeamForge data.

Back up and Restore TeamForge

If you are upgrading to a latest TeamForge version, it is still recommended to follow the usual backup and restore procedure. Use the teamforge.py script’s backup and restore commands if you want to back up a particular service such as CVS and restore it on a new server (when you intend to move a specific service from one server to another, typically to move the service to a dedicated server of its own).

If you are backing up TeamForge as a whole, you must stop all the TeamForge services but PostgreSQL before running the teamforge backup and teamforge restore commands.