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.
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>
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.).
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.).
# | Change | User | Description | Committed | |
---|---|---|---|---|---|
#3 | 25550 | C. Thomas Tyler |
Split HMS from SDP, such that HMS will live on as a separate product, layered on the SDP. See: https://swarm.workshop.perforce.com/jobs/SDP-356 Many of the files deleted here have already been copied to HMS. See these HMS changes: https://swarm.workshop.perforce.com/changes/25531 https://swarm.workshop.perforce.com/changes/25533 And this branch spec: SDP_Split_2019.2_HMS In mkrep.sh, HMS-awareness is removed from mkrep.sh, a core SDP script, and the '-f' (Full Setup) flag has been temporarily removed. This useful functionality will be restored in an HMS script. This is a big change, so shellcheck v0.6.0 was implemented to support it. |
||
#2 | 21921 | C. Thomas Tyler |
HMS change, to simplify setup on compliant platforms (i.e. those using bash 4.x). The shebang line for all bash scripts has been standardized to /bin/bash, and bash checks for $BASH_VERSION added where needed. References to having a custom-built /usr/local/bin/bash have been removed. As a trade-off, non-compliant platforms (way-old Linux and Mac using bash 3.x) will have a bit more work to do to work with shebang lines. |
||
#1 | 20745 | C. Thomas Tyler |
Approving as is since it isn't changing core SDP functionality, and reviewing it all line by line will take some time. We can do that as we move forward with it. First addition of HMS v1.0 files. This change is a soft launch HMS for initial deployment and testing. Updates to HMS-related files are expected and will bypass pre-commit code review until stabilized. |