Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


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).


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_duration to 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