Page MenuHomePhabricator

Deprecate phabricator's fixed_settings.yaml (in puppet) and just use phabricator's built in configuration tools
Open, LowPublic

Description

I would like to deprecate the fixed_settings.yaml (in puppet) and prefer just making customizations in the phab config gui with just a few security-critical settings to remain locked and managed via a plain json config file in puppet.

There are several reasons for this:

  1. The puppet code to compile a suitable phabricator config json (from a static yaml in puppet) is kind of a dirty hack implemented in ruby land (I believe via a puppet compiler function called ordered_json). Background: Internally, ruby hashes are unordered, while php stores hashes (aka associative arrays) in an order-preserving way. Further, phabricator cares about the order of keys in the config. In fact the order really matters a lot.
  2. There is already a nice GUI for editing phabricator's config that has several good features which we don't get when editing config via puppet:
    • The GUI does a lot of sanity checking on your new config values before applying them, a bad config change done by puppet can bring phabricator offline and it requires a time consuming git revert + puppet agent to bring things back to a working state.
    • The GUI has an audit trail for every edit. Of course, git/gerrit has this as well, but it mitigates some of the advantage that would otherwise be conferred by using gerrit & puppet.
    • Edits done in the GUI already override anything done in puppet so changes in puppet are sometimes ineffectual (see T228757: Rename Phabricator's "Normal" Priority field value to "Medium")
    • Phabricator already locks certain config settings so that they cannot be edited via the GUI, so security-critical settings must be managed by json files on disk (though there is a cli which does the same sanity checks as the phab gui). Nonetheless, we should at least eliminate the translation from yaml to json because it's slightly error-prone and provides very little benefit in terms of ergonomics (and it's a negative in terms of maintainability)

I have more thoughts on this but I'm supposed to be on vacation so I'll fill in more detail later.

Event Timeline

Would there still be some way to (automatically?) export (and import again) the Wikimedia Phabricator production settings, e.g. to deploy the same configuration to https://phab.wmflabs.org/ or to some local Phab instance if someone wants to be as close to Wikimedia Phabricator settings as possible?

I could write a script that filters out sensitive values and then dumps the configuration into a json file.

Aklapper added a subscriber: brennen.

Copying in comment from @brennen in T331673:

See discussion on https://gerrit.wikimedia.org/r/c/operations/puppet/+/877188 -

Have discussed this with Dzahn on IRC. It looks to me like the translation.override value is actually hardcoded in the deployment repo -

https://gitlab.wikimedia.org/repos/phabricator/deployment/-/blob/wmf/stable/scap/templates/phabricator/conf/local/local.json.j2#L295

That configuration template gets values from /etc/phabricator/config.yaml, which are in turn set from puppet.

This makes it seem like there's some redundant stuff in puppet that isn't actually getting applied to the Phabricator config, and fixed_settings.yaml here probably needs cleaned up.

Should make sure this is actually the case.