Config FAQ

The Config Runbook provides guidance on managing configurations across different override levels in an application environment. This guide helps troubleshoot common configuration issues, such as incorrect values, unauthorized access, and cache invalidation.

Copy link to this section

Understanding the Config Framework

For a detailed overview of the Config Framework, refer to the Config Framework Documentation. The configuration hierarchy includes overrides at various levels: USER, APP, ENV, CLUSTER, and ROOT. Configurations from these levels are merged in reverse order, where lower-level overrides take precedence.

Copy link to this section

Commonly faced issues

1. Incorrect Config Values

   • Cause: Multiple leader nodes servicing the app without cache invalidation enabled.
   • Solution:
     • In version 8.5, use DefaultCacheBroadcastConfig.make().enable(ConfigOverride.APP or ENV) for APP/ENV level eviction, and follow the documentation for Cluster level.

2. Setting Config or Secret Values

   • Issue: Unable to see updated values after setting config or secret.
   • Cause: Configurations are layered, and overrides at lower levels can overwrite higher levels.
   • Solution:
     • Verify there are no configs set at lower overrides than expected.
     • Use ConfType.make(<key>).loadConfigOverride(<override>) to examine raw JSON values at specific overrides.

3. Unauthorized to Set or Read Config/Secret Values

   • Setting Config Values:
     • Permissions vary by override level. APP-level overrides can be set by any authorized user.
     • ENV and CLUSTER level overrides require Env Admin and Cluster Admin permissions, respectively.
   • Reading Config Values:
     • No restrictions apply to config value reading, but secret values at ENV and CLUSTER levels require admin permissions.

4. Using set* vs. set*Value APIs

   • Difference:
     • set* APIs overwrite the entire JSON object at the specified override, potentially clearing other configurations at that level.
     • set*Value APIs only modify a single field without affecting other fields.

5. Seeded Configurations Not Showing Expected Values

   • Cause: Overrides set at any level will take precedence over seeded values.
   • Solution:
     • Verify override levels for conflicting fields.
     • Confirm package dependencies and versions align with seeded config values, as they are version-specific.

6. Unexpected Errors with Config Objects

   • Solution: Check the issues field in the config object to identify any deserialization errors:

     JavaScript

     Copy code to clipboard

     var conf = MyConfType.make().getConfig();
     conf.issues;

Copy link to this section

Frequently asked questions (FAQ)

Q: I updated a config value, but it's not reflected when I read it. What could be wrong?
A: Configurations might be layered with multiple overrides. Use loadConfigOverride(<override>) to confirm there are no lower-level overrides taking precedence.

Q: How do I ensure that cache invalidation is active for my application?
A: For version 8.5, use DefaultCacheBroadcastConfig.make().enable() with the specific override level (APP or ENV). For earlier versions, use CacheBroadcastConfig.make().enable().

Q: What permissions do I need to set or read secret values at different overrides?
A: Setting values at APP override requires app-level permissions, while ENV and CLUSTER overrides require Env Admin or Cluster Admin permissions. Reading secret values from ENV or CLUSTER levels also requires admin permissions.

Q: Why is my seeded config not showing expected values?
A: Check for conflicting values at any override level, as these take precedence over seeded values. Also, ensure package versions are consistent across dependencies, as seeded configs are version-dependent.

Q: What is the difference between set* and set*Value when configuring values?
A: The set* APIs overwrite the entire JSON object, potentially clearing existing configurations, while set*Value APIs change only a single field.