# The form data below was edited by perforce # 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-223 Status: closed Project: perforce-software-sdp Severity: C ReportedBy: tom_tyler ReportedDate: 2017/05/21 22:02:38 ModifiedBy: perforce ModifiedDate: 2019/02/19 10:50:50 OwnedBy: russell_jackson Description: Fix EDGESERVER check in p4d_base regression. Fix an issue introduced in @22215. The change introduces a check of the $EDGESERVER environment var in p4d_base, which isn't reliably set when p4d_base is called. Though p4d_base now sources in backup_functions.sh, which has logic to set the EDGESERVER variable in the set_vars() function, that set_vars() function is never actually called. We can't just call the set_vars() function, because it makes 'front door' checks (i.e. calls 'p4' commands) to determine if the current instances is an edge server. There are a few problems here: 1) The p4d_base is an init script, and so can't assume that front-door commands will work, since the server might be down. So the call to determine if it is an edge server won't give the right result, and the 'p4login' call will hang unnecessarily for a while. Proposed fixes: * Rewrite the logic in set_vers that sets EDGESERVER. It should detect whether the current server is an edge server in a way that runs fast and reliably even when 'p4d' is down. Do something like 'p4d -k db.<whatever> -jd -' and find which database has server specs, and match that value in th schema to the server spec (named $SERVERID), and check that the value for the 'Services:' field of the server spec has the code for 'edge-server.' * Rewite the set_vars() so it only does innocuous things like set variables (as the name implies), and doesn't try a 'p4 login'. or anything else "active." Warnign: Need to make sure that doesn't break anything, i.e. if any place calling set_vars() relies on it doing 'p4login'. This may need some refactoring and further testing. DevNotes: Component: init Type: Bug