# HMS v2.0 System Components

HMS v2.0 consists of the following components.

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

* **P4 Topology Config File** - A P4 Topology Configuration File that defines the global topology.  It knows every machine that contains P4 topology components of any kind (p4d, p4broker, p4p, etc.), 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://workshop.perforce.com/view/p4-sdp/dev/doc/SDP_Guide.Unix.html#_server_spec_naming_standard).

* **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:

```
# Implement P4 Helm Management System (hms) commands.
command: ^hms$
{
   action  = filter;
   execute = /p4/common/site/hms/scripts/broker_wrapper;
}
```

* **Bash 4.3** - Some HMS scripts use modern bash features such as associative arrays and regular expression comparisons.  Scripts that require Bash 4.x+ have a safety check to verify that a current enough version of bash is used.

* **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` script is used to manage all SDP scripts and configuration files, including SDP-related files, on all Perforce server machines , be they simple proxy machines, replicas or edge servers, or master/commit servers.  The `sdp_sync` 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 failover.  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.

* **P4 Code Review** A P4 Code Review service associated with the hms SDP instance, for the usual things it provides (web interface, code review, change notification via email/Slack, etc.).