• epriestley's avatar
    Provide more useful guidance if a repository is clusterized into an existing multi-device cluster · ccff4768
    epriestley authored
    Fixes T12087. When transitioning into a clustered configuration for the first time, the documentation recommends using a one-device cluster as a transitional step.
    However, installs may not do this for whatever reason, and we aren't as clear as we could be in warning about clusterizing directly into a multi-device cluster.
    Roughly, when you do this, we end up believing that working copies exist on several different devices, but have no information about which copy or copies are up to date. //Usually// they all were already synchronized and are all up to date, but we can't make this assumption safely without risking data.
    Instead, we err on the side of caution, and require a human to tell us which copy we should consider to be up-to-date, using `bin/repository thaw --promote`.
    Test Plan:
    $ ./bin/repository clusterize rLOCKS --service repos001.phacility.net
    Service "repos001.phacility.net" is actively bound to more than one device
    (local002.local, local001.phacility.net).
    If you clusterize a repository onto this service it will be unclear which
    devices have up-to-date copies of the repository. This leader/follower
    ambiguity will freeze the repository. You may need to manually promote a
    device to unfreeze it. See "Ambiguous Leaders" in the documentation for
        Continue anyway? [y/N]
    Read other changes.
    Reviewers: chad
    Reviewed By: chad
    Maniphest Tasks: T12087
    Differential Revision: https://secure.phabricator.com/D17169
PhabricatorRepositoryManagementClusterizeWorkflow.php 4.48 KB