# 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-22 Status: suspended Project: perforce-software-sdp Severity: C ReportedBy: michael ReportedDate: 2017/04/02 17:16:34 ModifiedBy: tom_tyler ModifiedDate: 2020/10/29 09:54:53 OwnedBy: russell_jackson Description: Create simple info SDP script to detail current settings, file locations, and basic usage. (sdp_info.py ?) Such a file will help customers and support personnel alike by giving quick insight into a particular configuration without having to refer to external doc or remember the particular names and locations of SDP files. For example: > sdp_info.py -h usage: sdp_info.py [-hsu] Show usage and setting information for the collection of scripts collectively known as the Server Deployment Package (SDP). -h print this message -s summary of server and connection info -u summary of usage infromation ====== ( -s summary option) master P4PORT: myhost:1666 case handling: sensitive broker: yes broker PORT: myhost:1888 proxy: no log file location: db file location: archive file location: See the instance_vars file for specific instance details: ====== ( -u usage option) Common commands: # setup /bin/master_run.py $INSTANCE_VAR/init.py # restart /bin/master_run.py $INSTANCE_VAR/ # daily checkpoint /bin/master_run.py $INSTANCE_VAR/ # weekly checkpoint and db rotation /bin/master_run.py $INSTANCE_VAR/ Note: Checkpoint operations on the master server instance can entail significant downtime. Recommend timing during low activity period and setting downtime expectation with end users. Warning: The weekly checkpoint and db rotation will... Administrators are advised to ensure that the backup db ifiles are up to date and uncorrupted by reviewing the logs in and verifying that checkpoints are completing and being moved without error. UPDATES: [ 2014-10-08 ttyler ] A requirement of this new 'sdp info' mechanism is that it should behave well with all versions of the SDP dating back to the first version submitted to p4prod (2007/10/08). That way, Support can distributed it to customers and ask them to run it to at least get some sense of what a customer has. It will be able to display more info for newer versions (e.g. those with a 'Id:' ktext marker in mkdirs.sh, and even newer ones with a 'Version' file to display). But should at least function with older versions, even if it's just wrapping 'p4master_run p4 set' for older versions (with instance defaulting to 1). [ 2014-09-18 amorriss ] The inclusion of a post-info trigger by default in all SDP installs could be used to flag the existence of the SDP; whether simply "echo SDP installed here" at least, better with some sanity check (the existence of a certain flag or file?) and retrieving 'p4 configure show' information and similar would be most useful. [ 2014-09-18 amorriss ] Once identified as an 'SDP' installation, then the info-gathering tools could be used. Alternatively, a 'p4 info' command could be reworked such that it does some self-identification and provides the output required. Note that some or more of the information requested is displayed by the following command: /p4/common/bin/p4master_run /p4/common/bin/p4 set DevNotes: This job, SDP-22, was originally named job000261. The answer to this job is: p4 -p server:port configure show or, for a an old server that doesn't have configure: /p4/common/bin/p4master_run p4 set No other special command/tool needed. Type: Feature