# The form data below was edited by tom_tyler # Perforce Workshop Jobs # # Job: The job name. 'new' generates a sequenced job number. # # Status: Job status; required field. There is no enforced or # promoted workflow for transition of jobs from one # status to another, just a set of job status values # for users to apply as they see fit. Possible values: # # open - Issue is available to be worked on. # # inprogress - Active development is in progress. # # blocked - Issue cannot be implemented for some reason. # # fixed - Fixed, optional status to use before closed. # # closed - Issue has been dealt with definitively. # # punted - Decision made not to address the issue, # possibly not ever. # # suspended - Decision made not to address the issue # in the immediate future, but noting that it may # have some merit and may be revisited later. # # duplicate - Duplicate of another issue that. # # obsolete - The need behind the request has become # overcome by events. # # Project: The project this job is for. Required. # # Severity: [A/B/C] (A is highest) Required. # # ReportedBy The user who created the job. Can be changed. # # ReportedDate: The date the job was created. Automatic. # # ModifiedBy: The user who last modified this job. Automatic. # # ModifiedDate: The date this job was last modified. Automatic. # # OwnedBy: The owner, responsible for doing the job. Optional. # # Description: Description of the job. Required. # # DevNotes: Developer's comments. Optional. Can be used to # explain a status, e.g. for blocked, punted, # obsolete or duplicate jobs. May also provide # additional information such as the earliest release # in which a bug is known to exist. # # Component: Projects may use this optional field to indicate # which component of the project a givenjob is associated # with. # # For the SDP, the list of components is defined in: # //guest/perforce_software/sdp/tools/components.txt # # Type: Type of job [Bug/Feature]. Required. # # Release: Release in which job is intended to be fixed. Job: SDP-540 Status: closed Project: perforce-software-sdp Severity: C ReportedBy: tom_tyler ReportedDate: 2020/06/02 14:37:52 ModifiedBy: tom_tyler ModifiedDate: 2021/08/14 08:57:15 OwnedBy: tom_tyler Description: Add sdp_upgrade.sh script to the SDP. Add a script to the SDP that knows how to upgrade the to the current version from earlier versions on a single machine, and can be run on multiple machines as part of a larger global topology upgrade process. The sdp_upgrade.sh requires the old SDP to be 2020.1 or newer. Each future version of the SDP will know how to upgrade from all prior releases, so long as the starting point is SDP 2020.1. or later. About this script: * This script will be safe to run in environments where live p4d instances are running, and will not require p4d to be stopped or upgraded. Upgrade of the SDP will be cleanly separated from the upgrade the Helix Core binaries, p4/p4d/p4broker/p4p. * Preflight checks will be done first, including requirng a successful verfify_sdp.sh call of the old version. Among other things, this will verify the the /p4/sdp/Version file exists and references the SDP 2020.1+. * This will ugprade from SDP 2020.1 and all future versions, but not from pre-2020.1 SDP versions. * For upgrading from pre-20.1 versions, the script will reference detailed documentation availabile in SDP 2020.1 for doing in-place or migration-style updgrades for SDP releases since the first official SDP release in 2007. The documentation will account for SDP changes over the years including structural changes, changes in format of init scripts, changes in the format of systemd *.service files, changes in generated and often customized shell environment files, etc. Due to blending of configuration and customization, automation of upgrades from pre-2020.1 releases is not being attempted. * This script will upgrade SDP script files, and provide guidance on any post-processing steps, e.g. adjustments to crontabs. * This will re-generate generated SDP configuraion files, including: - /p4/common/bin/p4_vars - /p4/common/config/p4_N.vars (for all instances) The re-generation logic will preserve current settings, and also preserve any customizations made below a special tag in those generated files that says: ### MAKE LOCAL CHANGES HERE Starting with SDP r21.1, custom logic will be moved to a new file, /p4/common/config/p4_N.vars.custom The logic will preserve anything below that tag. It will also preserve specific changes made above the tag. Changes preserved above the tag include the right-side of assignments for specific settings. For p4_vars, preserved setting values include: - OSUSER - SDP_VERSION For the instance_vars files, preserved setting values include: - MAILTO - MAILFROM - P4USER - P4MASTER_ID - SSL_PREFIX - P4PORTNUM - P4BROKERPORTNUM - P4MASTERHOST - P4MASTERHOST - PROXY_TARGET - PROXY_PORT - P4DTG_CFG - SNAPSHOT_SCRIPT - SDP_ALWAYS_LOGIN - SDP_AUTOMATION_USERS - SDP_MAX_START_DELAY_P4D - SDP_MAX_START_DELAY_P4BROKER - SDP_MAX_START_DELAY_P4P - SDP_MAX_STOP_DELAY_P4D - SDP_MAX_STOP_DELAY_P4BROKER - SDP_MAX_STOP_DELAY_P4P - VERIFY_SDP_SKIP_TEST_LIST - The 'umask' setting. Note that the above list excludes any values that are calculated. * The /hxdepots/sdp folder will be moved aside, and the new SDP deployed in /hxdepots/sdp. * The SDP_VERSION and SDP_DATE counters will be set. * This will be work for basic, non-HMS environments to simpfliy upgrades of the SDP, but will be compatible with HMS upgrade procedures and mechanisms (which will need some evolution to adapt to this). Component: setup Type: Feature