P4ServerHostNamingConvention.adoc #1

= P4 Server Host Naming Convention
Perforce Professional Services <[email protected]>
:revnumber: v2025.2
:revdate: 2026-05-08
:doctype: book
:icons: font
:toc:
:toclevels: 5
:sectnumlevels: 4
:xrefstyle: full
// Attribute for ifdef usage
:unix_doc: true

== DRAFT NOTICE

WARNING: This document is in DRAFT status and should not be relied on yet.  It is a preview of a document to be completed in a future release.

== Server host naming convention

This is recommended, but not a requirement for SDP scripts to implement failover.

* Use a name that does not indicate switchable roles, e.g. don't indicate in the name whether a host is a master/primary or backup, or edge server and its backup. This might otherwise lead to confusion once you have performed a failover and the host name is no longer appropriate.
* Use names ending numeric designators, e.g. -01 or -05. The goal is to avoid being in a post-failover situation where a machine with `master` or `primary` is actually the backup. Also, the assumption is that host names will never need to change.
* While you don't want switchable roles baked into the hostname, you can have static roles, e.g. use p4d vs. p4p in the host name (as those generally don't change).  The p4d could be primary, standby, edge, edge's standby (switchable roles).
* Using a short geographic site is sometimes helpful/desirable. If used, use the same site tag used in the ServerID, e.g. aus.  

ifdef::unix_doc[]
+
Valid site tags should be listed in: `/p4/common/config/SiteTags.cfg` - see <<_sitetags_cfg>>
endif::[]

* Using a short tag to indicate the major OS version is *sometimes* helpful/desirable, e.g. c7 for CentOS 7, or r8 for RHEL 8. This is based on the idea that when the major OS is upgraded, you either move to new hardware, or change the host name (an exception to the rule above about never changing the hostname). This option maybe overkill for many sites.
* End users should reference a DNS name that may include the site tag, but would exclude the number, OS indicator, and server type (`p4d`/`p4p`/`p4broker`), replacing all that with just `perforce` or optionally just `p4`.  General idea is that users needn't be bothered by under-the-covers tech of whether something is a proxy or replica.
* For edge servers, it is advisable to include `edge` in both the host and DNS name, as users and admins needs to be aware of the functional differences due to a server being an edge server.

Examples:

* `p4d-aus-r7-03`, a master in Austin on RHEL 7, pointed to by a DNS name like `p4-aus`.
* `p4d-aus-03`, a master in Austin (no indication of server OS), pointed to by a DNS name like `p4-aus`.
* `p4d-aus-r7-04`, a standby replica in Austin on RHEL 7, not pointed to by a DNS until failover, at which point it gets pointed to by `p4-aus`.
* `p4p-syd-r8-05`, a proxy in Sydney on RHEL 8, pointed to by a DNS name like `p4-syd`.
* `p4d-syd-r8-04`, a replica that replaced the proxy in Sydney, on RHEL 8, pointed to by a DNS name like `p4-syd` (same as the proxy it replaced).
* `p4d-edge-tok-s12-03`, an edge in Tokyo running SuSE12, pointed to by a DNS name like `p4edge-tok`.
* `p4d-edge-tok-s12-04`, a replica of an edge in Tokyo running SuSE12, not pointed to by a DNS name until failover, at which point it gets pointed to by `p4edge-tok`.

FQDNs (fully qualified DNS names) of short DNS names used in these examples would also exist, and would be based on the same short names.

[appendix]
== CHANGES UNDER DISCUSSION

We are reconsidering some aspects of the P4 Server Host Naming Convention

CHANGES to hostname convention:

* Change 'p4d-edge' to 'p4e'

POSSIBLE GOALS:

* Keep the name reasonably short.
* Make server's purpose obvious.
* Make server's team using the server obvious (ala Scopely).
* Make the server's general location obvious.
* Make the OS/platform obvious?
* Make it user-side DNS name for a server isn't affected by a 'p4 failover' 
* Make sure what shows up in 'hostname' in the prompt matches name as seen in AWS console (or Azure).

* p4cr - Not in the naming convention, but has been used for P4 Code Review, a standard name is to be discussed.

TIP: Using 'p4cr' for P4 Code Review is suboptimal, as it is too easly confused with other server type tags.

One idea:

p4c-bos - Short Name

Battle School Workshop Gen6 Names:

p4d-bos-01
p4d-bos-02
p4d-nyc-03
p4d-syd-04
p4d-syd-05

Battle School Workshop Gen7 Names:

p4c-bos-01
p4c-bos-02
p4c-nyc-03
p4e-syd-04
p4e-syd-05

Idea: This convention should be extended to include suggestions for CNAME and A records.

Options:

* <HostTypeTag>-<SiteTag>-NN
* <HostTypeTag>-<TeamTag>-<SiteTag>-NN

<HostType>:

* p4c - commit? OR, commit or standby of commit.
* p4d - commit? OR, commit or standby of commit.
* p4e - p4 edge; static.
* p4ffr - p4 filtered forwarding replica.
* p4p - proxy
* p4b - p4broker
* p4 - some kind of p4 tech???

DROP: * p4s - standby server 

Some sample host names:

* p4demo-commit-1
* p4demo-commit-2
* p4demo-commit-3

## Should we optimize for P4RA

* We assume 1 data set per instance; any given server machine is dedicated to one instance.
* We don't do reactive failovers very often in P4RA.

Key Questions:
* Is it accetpable to rename host names??? Or do they live forever per machine.


[appendix]
== DRAFT NOTICE

WARNING: This document is in DRAFT status and should not be relied on yet.  It is a preview of a document to be completed in a future release.