Skip to content

Configuration Advanced

Andrew MacGaffey edited this page Jul 25, 2026 · 9 revisions

Configuration: Advanced

This builds on Configuration: Basics. Basics covers setting values and seeing what is in effect; this page is how a deployment's configuration is actually assembled - the switches, the per-component settings files it pulls in, environment-variable substitution, and the fuller ways to inspect it.

Audience: Operator, Architect.


How a deployment's configuration is assembled

Every component ships with self-contained defaults, so in most cases it runs without configuration. A deployment adjusts those defaults through its deployment.properties - the operator entry point - and the per-component files it pulls in.

deployment.properties is kept short. It carries the switches and required values directly, and it pulls in one settings file per component through an includePaths list:

com.metafluent.blueprint.bootstrap.applicationConfig.includePaths=\
    $(METAFLUENT_CONFIG_OVERRIDES)/mf-session.properties,\
    $(METAFLUENT_DEPLOYMENT_CONFIG)/settings/com.metafluent.blueprint.rtc.session.server.tcpip.properties

The first entry is the image's own override layer, fixed by whoever built the image; the rest are the component settings files you edit. This list is generated - you change values in the settings files, not the include list itself.

The effective value of any property is therefore the shipped default, unless a switch, a required value, or a component's settings file overrides it. Each override is a literal value or an environment-variable reference resolved at startup. The self-report shows the default and the resolved actual side by side, so you can see which won.


Switches

Some choices are a single on/off decision rather than a value to tune - whether DACS authentication is active, which authorization provider a content adapter uses. These are switches, listed together at the top of deployment.properties. You set the value directly; there is nothing to include or swap.

For example, a session server either authenticates clients against DACS or accepts them unauthenticated:

com.metafluent.blueprint.rtc.session.server.tcpip.server.authenticationDomain=NO-AUTHN

The default is NO-AUTHN. To authenticate against DACS, set it to DACS and restart:

com.metafluent.blueprint.rtc.session.server.tcpip.server.authenticationDomain=DACS

A deployment typically has several switches - client authentication, whether a content adapter is disabled, and the like. Each is a plain value the component reads at startup, so its effect appears in the same self-report as any other property.


Environment-variable substitution

So that one deployable image adapts to a deployment without editing files per machine, values may reference environment variables:

  • $(NAME) - the value of NAME.
  • $(NAME:default) - the value of NAME, or default if it is not set.
  • $(NAME:) - the value of NAME, or empty if it is not set.

This is how host- and site-specific values - ports, hostnames, data directories, client networks - are threaded in from the deployment environment rather than hard-coded. For example, a setting may default to $(METAFLUENT_CLIENT_NETWORKS:), taking the value of that environment variable, or empty if the deployment does not set it.


Inspecting the effective configuration in depth

Configuration: Basics covers the two on-disk reports and the quick "what did I change" extraction. Going deeper, the config API answers two questions live over the gateway.

Each effective property, with its default. fullProperties returns all properties in effect - not only the ones you changed - each with its default and resolved actual:

curl -s "http://mf-api-gateway:9090/api/config/v1/*/fullProperties?bundleName=.*"
[ { "bundleName": "com.metafluent.blueprint.rtc.session.server.tcpip", "bundleVersion": "6.3.0",
    "properties": [
      { "name": "server.default",   "default": "8900", "actual": "8900" },
      { "name": "server.authenticationDomain", "default": "NO-AUTHN", "actual": "DACS" } ] } ]

The default vs actual pairing is the point: it tells you what each property resolved to and, at a glance, which ones differ from their shipped value.

Narrow by component. bundleName is a regex, so you can focus on one area:

curl -s "http://mf-api-gateway:9090/api/config/v1/*/fullProperties?bundleName=com.metafluent.blueprint.rtc.session.*"

Narrow by container. On a multi-container deployment, select one container's configuration with the image= predicate:

curl -s "http://mf-api-gateway:9090/api/config/v1/image=mf-mds-consolidated/fullProperties?bundleName=.*"

For only the properties that differ from their defaults, use allModifiedProperties in place of fullProperties (see Configuration: Basics).


Where to go next

Clone this wiki locally