HMS v1.0 System Components
===

HMS v1.0 consists of the following components.

* **Command Line Interface** - The `/p4/common/bin/hms` script.

* **Toplogy Config File** - A Helix Topology configuration file that defines the global topology.  It knows every machine that contains Helix topology components of any kind, and knows about SDP instances in your environment.

* **Naming Conventions** - HMS provides and requires a naming convention for ServerID values, server specs, and replication service users. See the [Server Spec Naming Standard](https://swarm.workshop.perforce.com/projects/perforce_software-sdp/files/main/doc/ServerSpecNamingStandard.md).

* **Broker Tidbit** - A custom p4broker entry allows some hms commands to be called from any client machine, such as `p4 hms status all`.  It looks like:

<PRE>
# Implement Helix Management System (hms) commands.
command: ^hms$
{
   action  = filter;
   execute = /p4/common/hms/scripts/broker_wrapper;
}
</PRE>

* **Bash 4.3** - Some HMS scripts use modern bash features such as associative arrays.  Scripts requiring bash 4.3+ have a shebang line of `#!/usr/local/bin/bash`; scripts without strict Bash 4 dependencies use a shebang line of `#!/bin/bash` (which can be bash 3.x or 4.x).

* **SSH Keys** - The SSH keys for the `perforce` user must be maintained to allow ssh access without a password (as needed for automation) among all managed machines.  SSH access must be bi-directional for any machines that are potential failover targets.  It need only be enabled mono-directional, outbound from the central server, for other replica types.

* **HMS Server** - The HMS Server is merely a dedicated SDP instance named "hms" (`/p4/hms`).  The `sdp_sync.sh` scirpt is used to manage all SDP scripts and configuration files, including HMS-related files, on all Perforce server machines , be they simple proxy machines, replicas or edge servers, or master/commit servers.  The `sdp_sync.sh` script encourages you to *run a tight ship*, taking advantage of Perforce to manage your production Perforce server machines.  For example, it detects unversioned changes to backup and failover scripts that might otherwise go unnoticed and possibly foil failvoer.  It tracks other details that can foil failover, such as incorrect crontab files for the `perforce` user on various machines.

 The job of the HMS Server is to keep the scripts and configuration files in sync during routine operation.  The HMS Server is not required to execute a failover.

* **Swarm** A Swarm instance associated with the hms SDP instance, for the usual things Swarm provides (web interface, code review, change notification via email, etc.).