# This is The Helix Topology configuration file. # #----------------------------------------------------------------------------- NAME=P4Demo VERSION=1.0.0 #----------------------------------------------------------------------------- # SDP Instances #----------------------------------------------------------------------------- # Form: INSTANCE|Name|UserPorts|MasterHost|ServerPort|BrokerPort|Managed|Desc # # Name is an SDP Instance name, e.g. matching /p4/<N> and the value used to # with 'source p4_vars' to source the environment for that instance. # Sample Value: fgs # # UserPorts is a comma-delimited list of actual P4PORT values used by users # to access the Perforce Helix versioning engine. These should be # host aliases and should not reference specific hardware. The numeric # part should reference a broker port if a broker is used, otherwise the p4d # port. For distributed installations, this should only reference P4PORT # values used to reference the master p4d server or a "stacked" broker (i.e. # a broker on the same host as p4d). If a list is provided, items after the # first can exclude the numeric portion, as it will be assumed to be the # same. Sample Value: perforce.mycom.com:1666,perforce,scm # # MasterHost is the hostname of the server machine on which the current master # p4d process runs. This name should refer to specific hardware. # Sample Value: bos-helix-01 # # ServerPort is the numeric port on which the p4d process runs on the master # host. Sample Value: 1999 # # BrokerPort is the numeric port on which the p4d process runs on the master # host. Sample Values: 1666 or Unset # # Managed: This is '1' if the instance is managed by HMS, or '0' otherwise. # HMS cannot attempt failover of unmanaged instances, but can be made aware # of them. Unmanaged instances are not required to use the SDP, and thus # random P4D instances can be captured here even thought they cannot be # managed. # Desc: A text description of the instance. INSTANCE|1|perforce:1666|helix-01|1999|1666|1|Battle School Lab Environment INSTANCE|hms|hms:4737|helix-02|4738|4737|1|Helix Management System #----------------------------------------------------------------------------- # Failover Targets #----------------------------------------------------------------------------- # Form: FAILOVER|Name|Type|MasterHost|BackupHost|InstanceList|Desc|Active # Name is a name of the Failover target. The Name itself is not required to # be unique, however the combination of the Name and any of the instances # in the InstanceList must be unique. That is, if there are two (or more) # entries named "HA" (for example) they cannot have any overlap in their lists # of instances in the InstanceList. # # Type is one of: Local, MO, Full # 'Local' indicates failover using the databases in /p4/<n>/offline_db on the # same machine, as opposed to failoing over to another machine. No host # alias name change is needed for Local failover, and the BackupHost field # should be Unset. # Possible Outcomes for Local Failover: 0 (Success), 1 (Failure) # # 'MO' indicates a Meta-Only failover. The assumption with an MO failover is # that archive files are safely managed on a "too big to fail" SAN or similar # shared storge, and thus that there is no need to be concerned with possible # archive file loss. The BackupHost must be defined for HA Failover. # Possible Outcomes for MO Failover: 0 (Success), 1 (Failure) # # 'Full' indicates a full failover, including metadata and archive files. The # assumption with a Full failover is that "recent" archive files at risk, and # must be verified. Only the most recent 10000 changelists are checked. # Possible Outcomes for Full Failover: 0 (Success), 1 (Failure), 2 (Qualified # Success). A Qualified Success is one in which metdata fails over successfully, # but some archive files are not available post-failover. # FAILOVER|local|Local|bos-helix-01|Unset|1|Local Failover|1 FAILOVER|master_ha|Full|bos-helix-01|bos-helix-01|1|High Availability|1 FAILOVER|master_dr|Full|bos-helix-01|nyc-helix-03|1|Disaster Recovery|1 FAILOVER|syd_ha|Full|syd-helix-04|syd-helix-05|1|Disaster Recovery|1
# | Change | User | Description | Committed | |
---|---|---|---|---|---|
#3 | 29183 | C. Thomas Tyler | Moved HelixTopology.cfg & sdp_hosts.cfg to site, added '.sample'. | ||
#2 | 25533 | C. Thomas Tyler |
Copied updated and new files from SDP into the new HMS "overlay" structure. A 'p4 copy' was done in all cases, so files in this change match what they did in the SDP. Corresponding files in the SDP are to be deleted. Some files will need modification to adapt to the new HMS structure, e.g. the 'setup' tree. |
||
#1 | 25531 | C. Thomas Tyler |
Refactored to receive merge from SDP. This structure emphasizes that HMS will be layered on the SDP. The tree is now structured to make it clear where files appear in an as-deployed configurtion, overlaid into the '/p4/common' structure of the SDP. The test suite is outside this structure, as it will not be deployed (due to dependencies on infratructure that won't likely appear in SDP production deployments). |
||
//guest/perforce_software/hms/dev/hms/test/HelixTopology.cfg | |||||
#2 | 20446 | C. Thomas Tyler | Set site name to P4Demo. | ||
#1 | 20312 | ttyler | Populate -o -b hms_sg_to_workshop. |