| Job | Status | Reported By | Description | Modified Date |
|---|---|---|---|---|
| SDP-913 | Open | giles | Support custom ulimit settings in *_base scripts. From a customer: I do have suspicion that the... script refresh_P4ROOT_from_offline_db.sh, which is part of SDP, is restarting the p4d server and then omits to start it with the settings (ulimit -S -c unlimited > /dev/null 2>&1) in /etc/profile. Per @giles: What is the right way to propagate such setting into SDP environment when doing the refresh_P4ROOT_from_offline_db.sh so this doesn't happen again and we can capture the core files? « | 2 years ago |
| SDP-911 | Open | C. Thomas Tyler | Fully document and implement parallel checkpoint support. With the completion of SDP-900, anyone... trained on the SDP can find how to enable parallel checkpoints by looking at the "instance vars" file, e.g. /p4/common/config/p4_1.vars. That contains the setting DO_PARALLEL_CHECKPOINTS, with documentation on how to enable parallel checkpoints. However, the SDP Guide doesn't yet mention the feature. Changing from a single-file checkpoint to a directory, while straightforward, is a far-reaching change with impacts in documention and other scripts. The command line to recover from a checkpoint directory is slightly different, and examples in docs and scripts need to be updated. Somethings that need to be reviewed and probably updated: * SDP Guide - Add new section on parallel checkpoints. * SDP Guide - Recovery procedures. * SDP Guide - Scour for all references to checkpiont ops. * Scripts that interact with checkpoints: - load_checkpoint.sh - mkrep.sh - edge_dump.sh - recover_edge.sh « | 2 years ago |
| SDP-910 | Open | Perforce maintenance | Added sdp_health_check.sh to the SDP. | about a year ago |
| SDP-905 | Open | Robert Cowham | verify_sdp.sh: Check contents/format of systemd *.service files.' | 2 years ago |
| SDP-902 | Open | C. Thomas Tyler | Upgrade p4dtate.sh, p4pstate.sh, and p4brokerstate.sh to be SDP-aware. Update the stock p4dstate....sh (and related p4pstate.sh and p4brokerstate.sh) to be fully SDP-aware without making them SDP-dependent. That is, if operating in an SDP environment with a defined structure and shell environment, take advantage of that to avoid the need to define things like placement of p4d/p4p/p4broker binaries. In an non-SDP environment, they will just work. Improvements planned to bring it up to SDP standards: * Add user documentation (-h and -man options), including guidance on when to run it, and where to send logs (e.g. to support-helix-core@perforce.com). * Make it the script never needs to be edited, e.g. using command line parameters and/or a configuration file. * Improve logging mechanism. * Make it reliable – the script should never hang, even if the p4d commands it tries to run hang. (Use 'timeout' utility to avoid hangs). Use bash, not sh. Pass ShellCheck (lint for bash) compliance. Add a '-update' option so the script can try to update itself with the latest version, e.g. via curl from the Perforce FTP server (will only work with external network connectivity; this limitation to be documented and also with an appropriate error message). There will be a copy of the new versions p4 p4dstate.sh, p4brokerstate.sh, and p4pstate.sh distributed with the SDP. « | 2 years ago |
| SDP-901 | Open | C. Thomas Tyler | SSO_default.ssh doesn't work with 'none' specified for SSO group name. | 2 years ago |
| SDP-899 | Open | C. Thomas Tyler | p4login needs '-all' option doc'd, with better usage validation. | 2 years ago |
| SDP-897 | Open | Andy Boutte | Remove all uses of `-k` in curl commands | 2 years ago |
| SDP-896 | Open | Andy Boutte | Stopping and starting p4d in refresh_P4ROOT_from_offline_db.sh should be optional. If I have a... scenario where p4d is already stopped I should be able to run refresh_P4ROOT_from_offline_db.sh without having to first start p4d. For example if my online database has corruption. « | 2 years ago |
| SDP-895 | Open | Andy Boutte | Enhance the p4d start up procedure to better handle the scenario where corruption is detected in the... journal file. The SDP can detect the corruption but all it does is rotate the journal. This leaves p4d functional but it leaves the offline database in a bad state. The next nightly offline checkpoint will fail when attempting to replay the latest journal files to the offline database. I think the SDP should do one of the following: 1) The most ideal situation is if the SDP can detect the corruption to first rotate the journal but then also run live_checkppint. This will get the offline database in a good state so that the next nightly offline checkpoint will succeed. 2) if there is no way to accomplish option #1 I think the SDP should have a configurable (opt in / opt out) to exit when corruption is detected in the journal file. « | 2 years ago |
| SDP-894 | Open | C. Thomas Tyler | For Windows SDP, add docs to add P4Diag autostart. See: https://portal.perforce.com/s/article/173...17 The binary is here: http://ftp.perforce.com/perforce/tools/p4diag/bin.ntx64/ The mission: Update the SDP Guide (Windows) to describe how to add P4DIAG Autostart to the SDP installation. With SDP, we know the p4s.exe lives in C:\p4\N\bin, and the P4DIAGLOG should be C:\p4\N\logs\p4diag_log.txt (or similar). So we'll need to do something like: p4 set -S p4_N P4DIAGLOG=C:\p4\N\logs\p4diag_log.txt « | 2 years ago |
| SDP-893 | Open | C. Thomas Tyler | Add optional method to prevent SDP P4USER from logging in without -a. When run on a p4d server wi...th multiple network interfaces, a super user ticket generated with 'p4 login' will break extensions and triggers, including breaking HAS. A 'p4 login -a' ticket is required for proper behavior. In SDP, the 'p4login' script, when used, generates the correct type of ticket (a '-a' ticket). The SDP scripts know to use this. However, there is no way to ensure that human admin won't run a 'p4 login' command (without the '-a'), resulting in extensiosns and triggers failing due to a bogus ticket. We should add something to the SDP to prevent the human admin from doing the wrong thing, i.e. logging in the 'perforce' super user with the wrong kind of ticket. Some options: * Request a p4d change to require '-a' login tickets. * Add a pre-commmand trigger so the perforce OS user, that rejects 'p4 login' without '-a'. * Add a broker REWRITE feature to implicitly add '-a' to 'p4 login' commands. (That won't be of much use though, since an admin working on the server generally uses a P4PORT value that bypasses the broker). « | 2 years ago |
| SDP-891 | Open | C. Thomas Tyler | Add logic to seemlessly handle interrupted live checkpoint. | 2 years ago |
| SDP-890 | Open | Robert Cowham | Add troubleshooting doc to handle interrupted live checkpoint. | 2 years ago |
| SDP-889 | Open | Robert Cowham | verify_sdp.sh needs to validate db.config root vs offline_db Drift in the values in db.config are... dangerous should we switch - need to be detected and reported! Obviously only appropriate for commit/edge not other replica types. « | 2 years ago |
| SDP-887 | Open | daniel_ferrara | mkrep.sh: Clarify which methods the script uses to determine P4TARGET. An explanation from @Tom T...yler of how the P4MASTERPORT value is defined in mkrepo.sh: If the -f <FromServerID> argument is used, which only applies when making a standby of an edge server, then the P4TARGET value is the ExternalAddress configureable associated with the given ServerID. Otherwise, the P4MASTERPORT value defined when you do source /p4/common/bin/p4_vars N. (where N is the SDP instance name; I can see this customer uses the default 1). Sourcing this file, which is the correct way to load the SDP environment, causes the /p4/common/config/p4_1.vars file to be sourced. Customer would like this clarified in the docs themselves: When I tested, I couldn't edit /p4/common/config/p4_1.vars file. If P4MASTERPORT was set with localhost default, is it possible to add a request that add explanation about the P4TARGET of replica server spec setting source? Docs: https://swarm.workshop.perforce.com/projects/perforce-software-sdp/files/main/Server/Unix/p4/common/bin/mkrep.sh Perforce-internal: See: P4-22418 « | 2 years ago |
| SDP-885 | Open | C. Thomas Tyler | Revise SDP script log handling so checkpoint.log is a symlink (Windows). In several places in SDP... script logging, there is a theme that the "simply named" file name, i.e. the log file without a date/time stamp, is always the most recent log. The 'checkpoint.log' is a prime example; there are several others, such as sync_replica.log. Having a consistent name to go to in order to see the latest log is very useful and familiar to SDP users. However, it also contributes to a problem where a log can get jumbled with contents from multiple runs of a script, e.g. if a checkpoint script scheduled to run daily runs for more than 24 hours, or if it is run concurrently by multiple human admins or crontab interfering with human admins (regardless of whether or not the given script supports concurrent operation). This job calls for a change so that scripts start writing a new log file immediately, and in early processing update the symlink to refer to the new log file name. Goals of this change: * No more script log jumbling or log file overwriting/corruption due to concurrent operation (or any other reason). * No changes required to documentation or operational procedures. For example, the familiar way of interacting with 'checkpoint.log' of doing a 'tail checkpoint.log' just after starting one of the scripts that write to checkpoint.log should work as expected. This would apply to the following: * checkpoint.log * sync_replica.log * replica_cleanup.log * request_checkpoint.log * recreate_offline_db.log * p4verify.log This job is for the Windows implementation; see SDP-884 for the UNIX/Linux implementation. « | 2 years ago |
| SDP-884 | Open | C. Thomas Tyler | Revise SDP script log handling so checkpoint.log is a symlink (UNIX/Linux). In several places in... SDP script logging, there is a theme that the "simply named" file name, i.e. the log file without a date/time stamp, is always the most recent log. The 'checkpoint.log' is a prime example; there are several others, such as sync_replica.log. Having a consistent name to go to in order to see the latest log is very useful and familiar to SDP users. However, it also contributes to a problem where a log can get jumbled with contents from multiple runs of a script, e.g. if a checkpoint script scheduled to run daily runs for more than 24 hours, or if it is run concurrently by multiple human admins or crontab interfering with human admins (regardless of whether or not the given script supports concurrent operation). This job calls for a change so that scripts start writing a new log file immediately, and in early processing update the symlink to refer to the new log file name. Goals of this change: * No more script log jumbling or log file overwriting/corruption due to concurrent operation (or any other reason). * No changes required to documentation or operational procedures. For example, the familiar way of interacting with 'checkpoint.log' of doing a 'tail -f checkpoint.log' just after starting one of the scripts that write to checkpoint.log should work as expected. (That checkpoint.log file is written to by daily_checkpoint.sh, live_checkpoint.sh, or rotate_journal.sh). * In any cases where gzip of old logs occurs, make sure that does not delay the start of core processing. For example, if the p4verify.log from an earlier run is very large, it may take many minutes gzipping the old log before new processing starts. This would apply to the following: * checkpoint.log * sync_replica.log * replica_cleanup.log * request_checkpoint.log * recreate_offline_db.log * edge_shelf_replica.log * upgrade.log * sdp_upgrade.log * journal_watch.log * p4verify.log * refresh_P4ROOT_from_offline_db.log * purge_revisions.log This would not apply to: * p4login.log (which may need a "noise reduction change"). * monitor_metrics.log This job is for the UNIX/Linux implementation; see SDP-885 for the Windows implementation. « | 2 years ago |
| SDP-883 | Open | C. Thomas Tyler | On Windows, sync_replica does not reliably clean old journals. === BEGIN LOG === Observed on a c...ustomer replica's sync.log: Start Sync Replica Wed 02/22/2023 04:00 AM xcopy /D /I \\P4DServer-04\F$\p4\1\checkpoints\*.* c:\p4\1\checkpoints\*.* \\P4DServer-04\F$\p4\1\checkpoints\p4_1.ckp.936.gz \\P4DServer-04\F$\p4\1\checkpoints\p4_1.ckp.936.gz.md5 2 File(s) copied Determining current journal counter with 'p4 counter journal'. Journal counter 936 found. ATTRIB -r c:\p4\1\checkpoints\*.925.* <-- The *.925.* does not del c:\p4\1\checkpoints\*.925.* catch the jnl file, so c:\p4\1\checkpoints\p4_1.jnl.925 the ATTRIB -r is not done. Access is denied. <-- The "Access is denied." is del c:\p4\1\offline_db\db.* because the ATTRIB is not done. c:\p4\1\bin\p4d.exe -r c:\p4\1\offline_db -jr -z c:\p4\1\checkpoints\p4_1.ckp.936.gz Perforce db files in 'c:\p4\1\offline_db' will be created if missing... Recovering from c:\p4\1\checkpoints\p4_1.ckp.936.gz... End Sync Replica Wed 02/22/2023 04:04 AM === END LOG === A possible solution is to change the 'DEL' command to 'DEL /F/Q', making the 'ATTRIB -R' unnecessary. Here are sample manual commands and outputs illustrating first change to the wildcard handling to make the ATTRIB apply to the journal, and then trying 'DEL' with the '/F/Q' options (thus no need for 'ATTRIB'). C:\p4\1\checkpoints>ATTRIB p4_1.jnl.225 A R C:\p4\1\checkpoints\p4_1.jnl.225 C:\p4\1\checkpoints>ATTRIB *.226.* A R C:\p4\1\checkpoints\p4_1.ckp.226.gz A R C:\p4\1\checkpoints\p4_1.ckp.226.gz.md5 C:\p4\1\checkpoints>ATTRIB *.jnl.226 A R C:\p4\1\checkpoints\p4_1.jnl.226 C:\p4\1\checkpoints>ATTRIB -r *.226.* C:\p4\1\checkpoints>ATTRIB -r *.jnl.226 C:\p4\1\checkpoints>ATTRIB *.226.* A C:\p4\1\checkpoints\p4_1.ckp.226.gz A C:\p4\1\checkpoints\p4_1.ckp.226.gz.md5 C:\p4\1\checkpoints>ATTRIB *.jnl.226 A C:\p4\1\checkpoints\p4_1.jnl.226 C:\p4\1\checkpoints>DEL *.226.* *.jnl.226 C:\p4\1\checkpoints>DEL /F /Q *.227.* *.jnl.227 « | 2 years ago |
| SDP-882 | Open | C. Thomas Tyler | load_checkpoint.sh fails if an old/expired license exists in offline_db. Following is a snippet i...n the log from the checkpoint where this failure occurs: ==================================================================== Cleaning up databases and offline_db_usable.txt file with this command in /p4/roku/offline_db: /bin/rm -f db.* state* /p4/roku/offline_db/offline_db_usable.txt Replaying checkpoint to offline_db with this command: /p4/roku/bin/p4d_roku -r /p4/roku/offline_db -jr /p4/roku/checkpoints/p4_roku.ckp.11477.gz Perforce db files in '/p4/roku/offline_db' will be created if missing... Recovering from /p4/roku/checkpoints/p4_roku.ckp.11477.gz... Ensuring databases in offline_db are upgraded with this command: /p4/roku/bin/p4d_roku -r /p4/roku/offline_db -t localhost:0.0.0.0 -xu Perforce server error: License file invalid. License expired. load_checkpoint.sh (line: 810): FATAL: Database upgrade in offline_db failed. « | 2 years ago |
| SDP-881 | Open | kathy_rayburn | Specify log date format for clarity and to avoid problems with some OSs. | 2 years ago |
| SDP-879 | Open | C. Thomas Tyler | Windows SDP can get stuck on log removal and hang. Details in Case00836544. | 2 years ago |
| SDP-875 | Open | C. Thomas Tyler | Auto-configure p4pcm.pl '-t{low|high}' thresholds per available storage. The Proxy Cache maintain...er script currently requires manual configuration of the crontab entry, configuring `-tlow` and '-thigh` thresholds. A good manual practice is to configure these thresholds to correspond to something like 97% and 92% available storage, so that the proxy space available oscilates between those numbers, keeping the cache largely full (for optimum benefit) but never filling up. The gist of this request is to provide an a way to look at output of, say, df -h /p4/N/cache and based on that, determine appropriate values to automate the manual practice. This could result in updating the crontab entry for p4pcm.pl, adding the '-tlow' and '-thigh' options. « | 2 years ago |
| SDP-870 | Open | Graeme Rich | Add new fedge ServerTypeTag to mkrep.sh if an edges uses *DataFilter fields. This will affect the... Server Spec Naming Standard and the mkrep.sh script. « | 2 years ago |
| SDP-863 | Open | C. Thomas Tyler | Update Server Spec Naming Standard to include daisy chaining. The standard illustrates an example... of daisy chaining a standby from an edge server, e.g. p4d_ha_edge_syd. But the General Form needs clarify and more examples are needed, e.g. a edge server chained from a forwarding replica. « | 2 years ago |
| SDP-859 | Open | Robert Cowham | Windows template_configure_new_server.bat set net.autotune=0 This seems to be causing quite frequ...ent hangs, especially over slow links and with large submits or syncs (e.g. UE5 size of 100k+ files 100GB+). « | 2 years ago |
| SDP-853 | Open | Domenic | p4verify.sh generates 'error: A revision range cannot be used here.' After running the p4verify.s...h script to validate shelved revisions there were multiple reports of "A revision range cannot be used here" in the email / log. However, it isn't clear *which* CLs were being tested so I'm not sure how to investigate them. The command ran was "/p4/common/bin/p4verify.sh INSTANCENAME -nr" and the log output was: === Started verify of shelved changelists at Tue Nov 22 21:21:30 PST 2022. Verifying 255528 shelved changelists. error: A revision range cannot be used here. exit: 1 error: A revision range cannot be used here. exit: 1 error: A revision range cannot be used here. exit: 1 error: A revision range cannot be used here. exit: 1 error: A revision range cannot be used here. exit: 1 error: A revision range cannot be used here. exit: 1 Of 255528 shelved changes verified, 6 had errors. « | 2 years ago |
| SDP-852 | Open | Perforce maintenance | Add recover_P4ROOT.sh to further automate recovery. Mode: Recovery from Checkpoint * Calls load_...checkpoint.sh with latest checkpoint and any needed journals up to and including live P4JOURNAL. * Does not depend on offline_db being in good shape. * Does not affect offline_db in any way. Mode: Recovery from offline_db * Fast mode using offline_db. * Can only be used if offline_db is in good shape. * Replays needed journals up to and including live P4JOURNAL. * Consumes offline_db. * Calls recreate_offline_db.sh script after service has been started or advises suer to do so. Should work for all server types: * Commit server * Standby * Edge, Filtered or not. * Replica, Filtered and/or Forwarding. « | 2 years ago |
| SDP-849 | Open | Karl Wirth | Check SDP Environment for OSUSER user, e.g. ~perforce/.bashrc, etc. | 2 years ago |
| SDP-847 | Open | Andy Boutte | Enable protected users that can't be easily deleted. Make the SDP P4USER (typically perforce, som...etimes p4admin) a protecteded user. « | 2 years ago |
| SDP-845 | Open | Robert Cowham | upgrade.sh: Doc, error message, and pedantic output improvements. * Enhance docs to make it super... clear p4d must be running at the start. * Enhance error message for the specific case where the only preflight check to fail is the one about p4d not being up, and say that if it was manually stopped, that it should be started before calling the script again. * Display the full command line of the call to verify_sdp.sh as made in upgrade.sh in the log, so the customer can run the same verify_sdp.sh command manually if they want. « | 2 years ago |
| SDP-841 | Open | Andy Boutte | Automated P4ROOT/license symlink creation. | 2 years ago |
| SDP-839 | Open | Andy Boutte | Document /p4/common/config/license and symlink handling. | 2 years ago |
| SDP-837 | Open | Perforce maintenance | Make force_start in p4d_N_init easier with systemd. The 'force_start' option to p4d_N_init script...s (coded in p4d_base) is easy to use when only raw SDP init scripts are used. That is, one can run 'p4d_1_init force_start' just as easily as 'p4d_1_init start'. Even the safety feature requiring systemctl to be used can be bypassed by calling the underlying init script with the force_start option. However, when systemd init scripts are used, as is typical in 2022, utilizing the force_start option while still using systemctl requires root access and familiarity with systemd to edit the systemd *.service file(s) for p4d, and then doing a 'systemctl daemon-reload' before restarting the service. Later, these steps must be undone when force starts are no longer required. Implementation Goals: * Avoid modifying the systemd *.service files, as changes to these require an update to the install mechanism. While possible, this is discouraged. Suggested Implementation: * Provide a second method of specifying a force start should be done, by touching a file /p4/N/bin/force_start. * Modify the p4d_base to check for existence of the force_start file, and if detected, behave as if 'force_start' had been used instead of start. * Make no changes to the systemd *.service file templates. Digression: Passing parameters to scripts called in systemd *.service files directly is not supported by systemd. It's possible with creative workarounds using the Environment field to read in settings from a file. For our purpose, a 'touch file' is all that is needed. Also: Document the intent of the force start option, and potential risks of using it. Without force_start, the init scripts refuse to start p4d if the databases in P4ROOT fail a 'p4d -xvU' safety check, indicating possible database corruption. « | 2 years ago |
| SDP-833 | Open | rwillyoung | Add docs and/or script to remove an SDP instance. This would be the opposite of mkdirs.sh. ... To do: Files to cleanup (pseudocode): rm -f /p4/common/config/.p4passwd.p4_<N>.* rm -f /p4/common/config/p4_<N>.* rm -rf /p4/<N>/bin rm -rf /p4/<N> rm -rf <HxDepots>/p4/<N>/ rf -rf <HxLogs>/p4/<N>/ rm -rf <HxMetadata*>/p4/<N>/ Some output from mkdirs helps show what to clean up: Running: chmod 700 /hxmetadata/p4 Running: chmod 700 /hxdepots/p4 Running: chmod 700 /hxlogs/p4 Running: chmod -R 700 /hxmetadata/p4/sample Running: chmod -R 700 /p4/common Running: chmod -R 700 /hxlogs/p4/sample Running: ln -s /p4/1/root/license /p4/sample/root/license Running: chown perforce:perforce /p4/sample/root/license Running: chmod 755 /p4/sample/bin/p4broker_sample_init Running: chmod 755 /p4/sample/bin/p4d_sample_init Running: chmod 600 /p4/common/config/.p4passwd.p4_sample.admin Running: chmod 600 /p4/common/config/.p4passwd.p4_sample.service « | 2 years ago |
| SDP-832 | Open | Robert Cowham | mkrep.sh config wrong for '-t ham' for an edge. | 2 years ago |
| SDP-831 | Open | rwillyoung | Doc enhancement: Auto-retrieving useful variables for scripting Hello! We have a number of Power... users/build engineers who are not OS level administrators of our SDP deployments. They will code scripts, triggers, and extendable functionality that they will then want implemented on the server, either via a cron job or via a trigger (often running from within the depot). We'd like to have a supported and maintained doc that helps people in the above scenarios understand that they can call p4_vars.sh and autopopulate useful variables for their script. This should contain examples with different script languages, including python and bash, and for windows folks powershell. Perhaps even maintaining templates that they can build their scripts/triggers on. Lastly if the doc could include simplified (user centric) steps on "you can ask your administrator to modify this file to implement your own variables that are called when p4_vars.sh is run", or if you have access yourself here's how to do it. « | 2 years ago |
| SDP-830 | Open | Andy Boutte | Set configurables for performance based on current hardware. The current configure_new_server.sh... just sets static values. It would be better when setting performance-related configurables, say the net.parallel.* configurables or various buffer sizes, based on current hardware. « | 2 years ago |
| SDP-828 | Open | Andy Boutte | Enhance upgrade.sh to safely apply new best practice configurables. | 2 years ago |
| SDP-826 | Open | C. Thomas Tyler | Suppress license warnings for servers not expected to have license files. | 2 years ago |
| SDP-822 | Open | C. Thomas Tyler | verify_sdp.sh: The test for exes in path depends on cwd if PATH includes dot. | 2 years ago |
| SDP-821 | Open | C. Thomas Tyler | p4verify.sh: skip shelve verification by default on edges if dm.shelve.promote=1. | 3 years ago |
| SDP-819 | Open | C. Thomas Tyler | Update configurables to best practices for r22.1. Some values: net.parallel.max=4 net.parallel....threads=4 net.parallel.sync.svrthreads= * No less 10 * No more than (4*$(cat /proc/cpuinfo | grep ^processor |wc -l)) dm.batch.net = 10000 client.sendq.dir=$P4ROOT/sendq « | 3 years ago |
| SDP-818 | Open | C. Thomas Tyler | Simplify SDP version and deprecate SDP_VERSION and SDP_DATE. Deprecate the SDP_DATE and SDP_VERSI...ON counters. Some changes needed: * The p4_vars.template must be changed to remove REPL_SDPVERSION. Change from: export SDP_VERSION="REPL_SDPVERSION" Change to: export SDP_VERSION="$(cat /p4/sdp/Version)" * The sdp_upgrade.sh will handle the new p4_vars.template during the next SDP upgrade. * The upgrade.sh will need to be aware of these counters. * The SDP Health Check script will need to NOT break. * Beware of impact to 'mkdirs.sh' when run with '-test' * Review configure_new_servers.sh so it doesn't set SDP_* counters. For the original 2007 pre-replication era of SDP, idea of having the managed p4d data set be aware of the SDP version made sense; back then the guidance was to version the SDP along with the customer's data. In modern times, this concept is obsolete. The SDP can manage multiple p4d data sets (aka SDP instances) on a given machine, but those data sets are extended via replication and proxies to many machines. The SDP version is bound to the machine, not the data set it manages. In fact the SDP can be different on different machines with the same data set. « | 3 years ago |
| SDP-815 | Open | Robert Cowham | verify_sdp.sh should summarise errors at the end It would be nice to finish by grepping the resul...ting log file for Error - something users otherwise has to do because errors are often hidden in the output. « | 3 years ago |
| SDP-814 | Open | Robert Cowham | mkrep.sh should mention SSL requirements in documented steps If you have SSL specified there are... some extra steps required to get a server working. Can be a bit surprising if you are not used to it. « | 3 years ago |
| SDP-811 | Open | C. Thomas Tyler | Eliminate Python2 dependency in SDP. Mostly that means changing the shebang line of scripts from: ... #!/usr/bin/env python to: #!/usr/bin/env python3 The scripts in /p4/common/bin/triggers already work with Python3. Others can be converted, perhaps with the 2to3 conversion tool if needed. See also: SDP-765 (Feature): Upgrade p4review2.py to work with Python 3. https://swarm.workshop.perforce.com/jobs/SDP-765 The Helix Installer deploys with the perforce-p4python3 package, which includes Python3 and P4Python. That is sufficient for all our needs; we have no need for Python2. « | 3 years ago |
| SDP-810 | Open | Domenic | Are there plans to incorporate 'p4 dbverify' into an SDP script? I looked at the p4verify.sh scri...pt included with the SDP https://swarm.workshop.perforce.com/projects/perforce-software-sdp/files/dev/Server/Unix/p4/common/bin/p4verify.sh as a way to validate our metadata with dbverify https://www.perforce.com/manuals/cmdref/Content/CmdRef/p4_dbverify.html but it isn't currently included. Before I start investigating adding it to the existing script, is it already planned to be added or setup as a separate script? If not, is there a preference for including it in p4verify.sh vs. a new script to make it easier to share back with the community? « | 3 years ago |
| SDP-809 | Open | Domenic | In a failover scenario with downstream replicas (e.g. https://swarm.workshop.perforce.com/projects/...perforce-software-sdp/view/main/doc/SDP_Failover_Guide.html#_resetting_downstream_replicas in addition to the 'state' file should the 'statejcopy' and 'journal.xyz' files also be renamed if they exist so that all metadata is retransferred? « | 3 years ago |
| SDP-807 | Open | C. Thomas Tyler | sdp_upgrade.sh: Add ownership checks HxDepots/sdp, HxDepots/p4/common. Ownership of files under /...hxdepots/sdp and /hxdepots/p4/common by any user other than the defined OSUSER (typically 'perforce') will not be detected during a dry run, but will cause an upgrade to abort safely and harmlessly in early-phase processing. Even better behavior would be to detect the issue of incorrect file ownership in the dry run. Verify ownership of all files under /hxdepots/sdp and /hxdepots/p4/common, the two directories modified by sdp_upgrade.sh, and make sure all of the correct OSUSER ownership. If not, abort with an appropriate error message. The default value for HxDepots is /hxdepots. « | 3 years ago |