mirror of
https://we.phorge.it/source/phorge.git
synced 2024-11-15 11:22:40 +01:00
bc4187d709
Summary: Ref T10759. We may "discover" the presence of a fatal setup error later, after starting Phabricator. This can happen in a few ways, but most are unlikely. The one I'm immediately concerned about is: - Phabricator starts up during a disaster with some databases unreachable. - We start with warnings (unreachable databases are generally not fatal, since it's OK for some subset of hosts to be down in replicated/partitioned setups). - The unreachable databases later recover and become accessible again. - When we run checks against them, we discover that they are misconfigured. Currently, "fatal" setup issues are not truly fatal if we're "in flight" -- we've survived setup checks at least once in the past. This is bad in the scenario above. Especially with partitioning, it could lead to mangled data in a disaster scenario where operations staff makes a small configuration mistake while trying to get things running again. Instead, if we "discover" a fatal error while already "in flight", reset the whole setup process as though the webserver had just restarted. Don't serve requests again until we can make it through setup without hitting fatals. Test Plan: - Started Phabricator with multiple masters, one of which was down and broken. - Got a warning about the bad master. - Revived the master. - Before: Phabricator detects the fatal, but keeps serving requests. - After: Phabricator detects the fatal, resets the webserver, and stops serving requests until the fatal is resolved. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10759 Differential Revision: https://secure.phabricator.com/D16903
64 lines
1.6 KiB
PHP
64 lines
1.6 KiB
PHP
<?php
|
|
|
|
final class PhabricatorSetupEngine
|
|
extends Phobject {
|
|
|
|
private $issues;
|
|
|
|
public function getIssues() {
|
|
if ($this->issues === null) {
|
|
throw new PhutilInvalidStateException('execute');
|
|
}
|
|
|
|
return $this->issues;
|
|
}
|
|
|
|
public function getUnresolvedIssues() {
|
|
$issues = $this->getIssues();
|
|
$issues = mpull($issues, null, 'getIssueKey');
|
|
|
|
$unresolved_keys = PhabricatorSetupCheck::getUnignoredIssueKeys($issues);
|
|
|
|
return array_select_keys($issues, $unresolved_keys);
|
|
}
|
|
|
|
public function execute() {
|
|
$issues = PhabricatorSetupCheck::runNormalChecks();
|
|
|
|
$fatal_issue = null;
|
|
foreach ($issues as $issue) {
|
|
if ($issue->getIsFatal()) {
|
|
$fatal_issue = $issue;
|
|
break;
|
|
}
|
|
}
|
|
|
|
if ($fatal_issue) {
|
|
// If we've discovered a fatal, we reset any in-flight state to push
|
|
// web hosts out of service.
|
|
|
|
// This can happen if Phabricator starts during a disaster and some
|
|
// databases can not be reached. We allow Phabricator to start up in
|
|
// this situation, since it may still be able to usefully serve requests
|
|
// without risk to data.
|
|
|
|
// However, if databases later become reachable and we learn that they
|
|
// are fatally misconfigured, we want to tear the world down again
|
|
// because data may be at risk.
|
|
PhabricatorSetupCheck::resetSetupState();
|
|
|
|
return PhabricatorSetupCheck::newIssueResponse($issue);
|
|
}
|
|
|
|
$issue_keys = PhabricatorSetupCheck::getUnignoredIssueKeys($issues);
|
|
|
|
PhabricatorSetupCheck::setOpenSetupIssueKeys(
|
|
$issue_keys,
|
|
$update_database = true);
|
|
|
|
$this->issues = $issues;
|
|
|
|
return null;
|
|
}
|
|
|
|
}
|