# SDP Server Spec Naming Standard With this naming convention, server spec names (aka ServerID) provide info at a glance - where the server is physically located, whether it is filtered, and hints about its intended usage and capabilities. ## General Form The general form of a server spec name is: *HelixServerTag*\_*ReplicaTypeTag*[*n*]\_*SiteTag* ## Helix Server Tags The *HelixServerTag* is one of: * `p4d`: for a Helix Core server (including all usages such as master/replica/edge). * `p4broker` * `p4p` * `p4gf`: Git Fusion * `gconn`: (Helix4Git Connector) * `swarm`: Helix Swarm As a special case, the "*HelixServerTag*_" is omitted for the ServerID of the master server spec. ## Replica Type Tags *ReplicaType* is one of: * `master_`*instance*: The single master-commit server. The *instance* is the SDP instance name. SDP instance names are included in the ServerID for the master, as they intended to be unique within an enterprise. They must be unique to enable certain cross-instance sharing workflows, e.g. using remote depots. * `ha`: High Availability. This indicates a replica that was specifically intended for HA purposes and for use with the `p4 failover` command. It further implies the following: * The Services field value is `standby`. * The `rpl.journalcopy.location=1` configurable is set. * The replica is not filtered in any way (No usage of `-T` to `p4 pull` in the replicas startup.*N* configurables, and no usage of `*DataFilter` fields in the server spec). * An `ha` replica replicates versioned files files (but see `ham` below). * An HA replica is assumed to be geographically near its P4TARGET server, which can be a master server or an edge server. It may or may not use the `mandatory` option; the `ha` tag does not indicate whether this is used or not. * `ham`: Similar to an `ha` replica, but a metadata-only replica that shares versioned files with its P4TARGET server (master or edge). * `fr`: Forwarding Replica (unfiltered) that replicates versioned files. * `fs`: Forwarding Standby (unfiltered) that replicates versioned files. * `frm`: Forwarding replica (unfiltered) that shares versioned files with its target server rather than replicating them. * `fsm`: Forwarding standby (unfiltered) that shares versioned files with its target server rather than replicating them. * `ffr`: Filtered Forwarding Replica. This replica uses some of filtering, such as usage of `*DataFilter` fields of the server spec or `-T` flag to `p4 pull` in the replicas startup.*N* configurables. Filtered replicas are not viable failover targets, as the filtered data would be lost. * `ro` - Read Only replica (unfiltered, replicating versioned files). * `rom` - Read Only and metadata-only replica (unfiltered, sharing versioned files). * `edge` - Edge servers. (As edge servers are filtered by their nature, they are not valid failover targets). ## Site Tags *SiteTag* looks something like these samples: * syd: Sydney, Australia * bos: Boston, MA, USA * blr: Bangalore, India The site tag needs to distinguish the data centers used by a single enterprise, and so generally short tag names are appropriate. Each site tag may be understood to be a true data center (Tier 1, Tier 4, etc.), a computer room, computer closet, or reserved space under a developer's desk. In some cases organizations will already have their own familiar site tags to refer to different sites or data centers; these can be used. In public cloud deployments, the public cloud provider's region names can be used (e.g. us-east1), or an internal form (e.g. awsnva for AWS in Northern Virginia, USA). As a special case, the "*SitgTag*" is omitted for the ServerID of the master server spec. ## Examples Here are some sample server spec names based on this convention: * `master_1`: A master server for SDP instance 1. * `p4d_ha_chi`: A High Availability (HA) server, suitable for use with `p4 failover`, located in Chicago, IL. * `p4d_ha2_chi`: A second High Availability server, suitable for use with `p4 failover`, located in Chicago, IL. * `p4d_ffr_pune`: A filtered forwarding replica in Pune, India. * `p4d_edge_blr`: An edge server located in Bangalore, India. * `p4d_ha_edge_blr`: An HA server with P4TARGET pointing to the edge server in Bangalore, India. * `p4d_edge3_awsnva`: A 3rd edge server in AWS data center in the us-east-1 (Northern Virginia) region. ## Implications of Replication Filtering Replicas that are filtered in any way are not viable candidate servers to failover to, because any filtered data would be lost. ## Other Replica Types The naming convention intentionally does not account for all possible server specs available with p4d. The standard accounts only for the distilled list of server spec types supported by the SDP `mkrep.sh` script, which are the most useful and commonly used ones.