...
A setting set via automation should smell like a bug most of the time (except in CC, where we’re OK with custom defaults).
A setting can use a sentinel such as zero or ““ for its default then document that this value causes the some special case or dynamic behavior instead, for example “0 = GOPAXPROCs” or “0 = no limit”. However the definition of the default itself should use a constant, not derived from an env var, flag or runtime/compiler value that could differ between nodes (though making the constant metamorphic for testing is allowed and encouraged).
Visibility
Guideline: Do not make a setting “public” unless:
...
Possibly mark the flag as “Hidden”.
Consider not using a CLI flag at all for unsafe configuration. See the next section instead
Guideline: If the same aspect of a behavior must be controllable by both a cluster setting and a per-node flag/env var, the flag/env var should override the cluster setting.
Having both is confusing and should be avoided if possible, however in cases where both exist…
Flags and env vars as per-node, which means they are more specific and should thus override cluster-wide settings.
Example: a cluster setting might set the
storage.max_sync_durationto 5s on a cluster where that is based on the most common disk configuration, while some nodes in that cluster might have different disks and/or other applications specific to those nodes sharing those specific disks and thus need to specify a different value.
Ad-hoc back-end configuration overrides
...