The Server Deployment Package (SDP) provides a set of management scripts for operating various Perforce software products, such as:
For p4d in particular, the SDP provides a sample implementation of best practices, such as performing offline checkpoints, rotating logs and journals routinely, and doing a database sanity/safety check before starting the server.
The SDP provides a structure for operating multiple instances of Perforce on a given machine, allowing for the possibility of each instance having different configuration aspects, e.g.
Perforce Jobs are used to file bugs and request enhancements to the SDP. The list of jobs (other than closed ones) can be viewed here.
You can see all jobs (including closed ones if desired) from the command line interface. Connect to The Workshop and run the <code>p4 jobs</code> command, something like this:
<code>p4 jobs -l -e "Project=perforce-software-sdp ^status=closed"</code>
There is no formal roadmap for the SDP, though it continues to evolve alongside P4D and other Helix components it manages.
Contributions to the SDP are most welcome! Note that contributing requires a basic user knowledge of working with Perforce.
All registered Workshop users have open access (but not write) to the SDP, specifically to this path:
The open access level confers the ability to edit and shelve changes for a pre-commit review process. We'll review the change, and either incorporate it or provide feedback. Be sure to provide a detailed change description, and also include the tag/text "[review]" in your changelist description to initiate a Swarm code review.
Optionally, you may also branch the SDP folder, or some subset of it, into your own guest area. Creating a branch spec is recommended for this purpose, e.g. with a branch spec like this:
Branch: your_name-sdp Owner: your_name Description: SDP Updates by your_name. Options: unlocked View: //guest/perforce_software/sdp/main/Server/Unix/etc/... //guest/your_name/sdp/main/Server/Unix/etc/...
If you branch a subset, it's a good idea to maintain the full path structure (as in the example above), so you can easily expand the scope of what you branched initially at some later date.
Edit, test and submit changes in your branch. Then when you are done, merge your changes back into our mainline, shelving them for review.
In line with the "Version Everything" mindset, the SDP itself should be versioned in your environment.
Commonly the SDP is versioned in a depot such as <code>//Perforce</code> or <code>//p4admin</code>, with a structure like this: <PRE> //p4admin/p4c/sdp/... //p4admin/main/sdp/... //p4admin/host/hostname/p4/1/bin/... </PRE>
The p4c and main folders are branches. The p4c branch is designated for receiving generic SDP updates from The Workshop. The main branch is where local customizations and/or configuration changes are applied.
The host folder contains instance-specific and host-specific files, which effectively communicate part of your topology. These define which services are active on which hosts.
On the Perforce server machines, basic workspaces are used to manage the SDP.
Recent versions of the SDP contain a <code>.p4ignore</code> file that helps avoid versioning of files that do not belong in version control, things like password files, editor temp files, and generated/compiled Python cache files.
When installing Perforce Swarm or Perforce Git Fusion in the SDP structure, they can and should be deployed in a way so as to benefit from the SDP structure, e.g. instances of Swarm and/or Git Fusion to run against each p4d instance.
Details for doing this are not yet incorporated the mainline SDP, though they have been deployed at customer sites. However, the basic ideas are fairly straightforward. As a hint for Swarm, you'll want to apply the <code>SWARM_DATA_PATH</code> in the httpd configuration to reference Swarm for each SDP instance.
If you have an earlier version of the Server Deployment Package (SDP) installed, you'll want to be aware of the new <code>-test</code> flag to the SDP setup script, <code>mkdirs.sh</code>. The following update instructions assume a simple, single-server topology.
Get the new software from The Workshop, which you'll find in the form of a SDP.Unix.*.tgz zipped tar file. Put the tar file in the <code>/depotdata</code> folder on your server. BE SURE TO MOVE THE OLD <code>/depotdata/sdp</code> folder aside first if it is there, e.g. to <code>/depotdata/sdp.old.2014-10-08</code>.
Then unpack it like this:
tar -xzvpf SDP.Unix.2015.1.####.tgz cd /depotdata/sdp/Unix/setup
Modify the mkdirs.sh script to suit your environment (possibly borrowing values from your old <code>mkdirs.sh</code> script).
Then run it:
mkdirs.sh 1 -test
That'll do a mock install, creating a <code>/tmp/p4</code> structure, with folders like <code>/tmp/p4/common/bin</code> and <code>/tmp/p4/1/bin</code>. The output will suggest some <code>diff -r</code> commands to run to to view the diffs and apply updates manually, being careful not to lose any customizations or local configuration changes you may have made.
If the SDP itself is versioned in Perforce in your environment, you can also put the new things from /tmp/p4 into your Perforce server where the SDP is. Commonly, there is a branch for receiving pristine updates of the generic SDP, e.g. 'p4c', which allow you to use Perforce merging to merge update into your local SDP mainline.
Contact Perforce Consulting Services to ask about engaging professional services to upgrade the SDP for you.
A few quick things to be aware of:
The old <code>p4_1_init</code> script (more generically <code>p4_instance_init</code>) was renamed to <code>p4d_1_init</code>. This will require updates to init script or symlink, e.g. in <code>/etc/init.d</code>.
The SDP structure enables two major views of a Perforce server, the system administrator/storage architect view, and the application administrator view. THe system admin sees this structure:
/depotdata /metadata /logs
System administrators know they need to backup <code>/depotdata</code>. Backing up <code>/logs</code> is optional, and /metadata is to be avoided by backup utilities, virus scanners, and anything else that might touch files in that area. This view is designed for optimizing for performance, as each of those folders has different performance profiles and usage patterns demanded by p4d. This view is not concerned with how many instances there are, or how they vary.
Application administrators (Perforce Admins), though a structure of symlinks, see Perforce from a view like this:
/p4/1/bin /p4/1/config /p4/1/depots /p4/1/root /p4/1/ssl /p4/1/tmp /p4/common/bin
This structure illustrates an instanced named '1' (it need not be numeric), as a /p4/common area which contains files common to all instances. Each of those folders is physically stored under an appropriate storage folder or volume as defined in the system admin view above.
The <code>/p4/instance/bin</code> folder defines which Perforce products are active for that instance on the current machine (p4d, p4broker, p4p, etc.). The root folder contains P4ROOT, while depots contains archive files.
The SDP provides standard mechanism for defining a controlled shell environment. This benefits p4d and other Perforce software products directly, and also provides good examples of controlling the environment for supporting automation, such as Perforce standards guidance and policy enforcement scripts (e.g. p4d triggers or p4broker filter scripts).
For advanced deployments, the SDP defines a standard for installing and configuring derived APIs, such as P4Python into /p4/common/python.
Many Perforce customers use the SDP as-is. Others benefit by incorporating concepts and ideas from the SDP into their own environments.
There are two flavors of the SDP, Unix and Windows. Both are available in the same folder structure in the Workshop.
There is automated tests using Vagrant for the Unix variant of the SDP. See test/README.md for details.
Clarified that Maintenance folder scripts are samples and are
NOT officially supported.
Updated references to HMS now that it has been split back out
into a separate product.
|#13||25155||robert_cowham||Refer to test/README.md|
Prepared patch SDP/MultiArch/2018.1/23583.p2
* In README, moved 'Supported Open Source Software' section
to the top of the page, to make Support position more visible.
* Copyright updated to 2019.
* Cleanup of excess script recreate_db_sync_replica.sh
* Re-removal of previously deleted script recreate_db_checkpoint.sh,
and corresponding removal from test suite.
* This patch tarball will also contain some Docker test suite updates
already staged in main.
By-passing review to trigger an automated test.
Fixed an obvious doc typo in README files. Bypassing code
|#10||23353||tom_tyler||Fixed typo/grammatical error.|
Overhauled SDP README page to better convey its value, and
much more strongly promote the SDP.
This also documents the the nature of offical Perforce Support
for the SDP, and the limitations of that Support to core SDP
Routine Merge Down to dev from main using:
p4 -s merge -n -b perforce_software-sdp-dev
|#7||15797||tom_tyler||Routine Merge Down to dev from main for SDP.|
|#6||13729||tom_tyler||Tweaked formatting on README.md.|
|#5||12028||tom_tyler||Refreshed SDP dev branch, merging down from main.|
|#4||11535||russell_jackson||Updated dev from main.|
|#3||11463||russell_jackson||Updated dev to prepare for Summit agreed changes.|
|#2||11038||robert_cowham||Catchup from Main|
|#1||10611||tom_tyler||Added README file for the SDP in The Workshop.|