Helix Core is now P4 and Helix Swarm is now P4 Code Review. Product user interfaces will be updated soon. Learn more >>

Documentation | 2025.3

# Commit-edge deployment

P4 Code Review can connect to a P4 Server configured to use the commit-edge architecture, which is a specific replication configuration that employs a commit server and one or more edge servers. This configuration distributes the compute, storage, and network requirements for improved performance and geographic distribution.

For more information on P4 Server's commit-edge architecture, see the Commit-edge chapter in the P4 Server Administration Documentation.

P4V users may have problems when P4V connects to an edge server and your commit and edge tickets are different. For more information on P4V authentication for commit-edge deployment, see P4V Authentication.

## P4 Code Review commit-edge configuration

This section describes what configuration changes need to be made to P4 Code Review and the P4 Servers to run P4 Code Review with a commit-edge deployment. Before you begin making changes ensure that your P4 Server commit-edge deployment is working correctly, and that P4 Code Review has been installed and configured.

Configure P4 Code Review for a commit-edge deployment:

1. Configure P4 Code Review to connect to the P4 Commit server, see P4 Code Review configuration. This is called the Commit Server P4 Code Review Instance.

When P4 Code Review is connected to the Commit Server P4 Code Review Instance, the first worker detects this situation and sets a key in the P4 Server, `P4.Swarm.CommitURL`, to an auto-detected URL.

2. Configure the P4 Code Review triggers:
   1. Configure the P4 Code Review triggers on all of the Commit and Edge servers, see Installing triggers.
   - Save all of the P4 Code Review trigger scripts in exactly the same place on each of the Commit and Edge servers. This is important because they all share the same trigger table.
   - You must install the trigger dependencies on all of the Commit and Edge servers, see Trigger dependencies.
   2. Configure SWARM_HOST in the swarm-trigger.conf file of all of the Commit and Edge servers to point to the Commit Server P4 Code Review Instance, see Installing triggers.
3. Configure all of the Commit and Edge servers to point to the Commit Server P4 Code Review Instance URL. This is done by setting the P4.Swarm.URL to the Commit Server P4 Code Review Instance URL on each of the Commit and Edge servers, see Swarm integration properties in the P4 Server Administration Documentation.
4. Your P4 Code Review configuration is now complete but you must check that it is working correctly before using it in production, see Validate your P4 Code Review installation.

Configure edge servers to promote shelved changes

If your P4 Server is configured as a commit-edge deployment, and your normal connection is to an edge server, P4 Code Review refuses to start reviews for shelved changes that have not been promoted to the commit server.

Within P4 Code Review, this means that the Request Review button does not appear for unpromoted shelved changes. Outside of P4 Code Review, attempts to start reviews for unpromoted shelved changelists appear to do nothing. Ask your P4 Server administrator for assistance if you cannot start a review.

An administrator of the P4 Server can automatically promote shelved changes to the commit server by setting the configurable `dm.shelve.promote` to `1`.

## P4V Authentication

When using P4V's P4 Code Review integration in a commit-edge deployment, users may encounter authentication errors; such errors can result from incorrect configuration of login tickets in distributed environments. Essentially, the problem is that while P4V is connected to an edge server, P4 Code Review is connected to the commit server, and the login tickets do not match.

If P4V users see the `error Host requires authentication`, the solution we recommend is to forward login requests to the commit server. This can be achieved by executing the following commands as a user with operator or super privileges in the P4 Server.

For example, the following p4 configure set commands run against the commit server set auth.id globally and enable login forwarding from the edge1 and replica1 servers:

    p4 configure set auth.id=myAuthName
    p4 configure set edge1#rpl.forward.login=1
    p4 configure set replica1#rpl.forward.login=1

Replace `myAuthName` with the authentication identifier for your P4 Server.

For more information, see our Knowledge Base article Single Ticket Login in Distributed Environments, and the `p4 serverid` command in the P4 CLI Reference.

### Troubleshooting: Azure Application Gateway issues with P4 Code Review and P4V

When running P4 Code Review behind an Azure Application Gateway (such as when using a load balancer with P4V), you may encounter authentication issues due to missing client IP information.

To resolve this, you need to configure the Azure Application Gateway to include an X-Forwarded-For header. Specifically, add a rewrite rule to insert or preserve the X-Forwarded-For header so that P4 Code Review can correctly identify the original client IP address. This can only be done by the Azure administrator managing your environment. It is not performed by P4 Remote Administration.

For more information, see Configuring Azure Application Gateway for accessing Kibana.

Your search for returned results