MOC — Configuration and Administration

The subsystem managing configuration, clusters, and application deployment. Java. Applications
are deployed to the config server; nodes subscribe to derived configs via a node-side proxy,
and the config model turns a deployed application package into concrete config instances.
(Description from vespa/Code-map.md; sizes from first-hand find/wc inspection.)

Modules

• vespa/configserver — server applications deploy to; serves derived configs (354 files,
  ~44k LOC).
• vespa/config-model — model of the running system derived from a deployed application;
  returns config instances per config type + config id (1054 files, ~132k LOC).
• vespa/config — client library (Java + C++) for subscribing to and reading config payloads
  (337 files, ~29k LOC). Also contains the C++ sources (observed: src/vespa/config,
  client, helper subdirs).
• vespa/configgen — generates C++/Java config classes from config definitions (25 files).
• vespa/config-proxy — node-side proxy between config subscriptions and the config server.
• vespa/configdefinitions — shared config type definitions referenced by many modules
  (23 files, mostly .def — only ~126 LOC counted because defs aren’t Java/C++).

Related unmapped modules observed in vespa/: config-lib, config-model-api,
config-application-package, config-bundle, config-provisioning, configd,
configserver-flags, configutil, config-class-plugin, config-model-fat.

Anchor files

• vespa/configserver/src/ — deployment + config serving.
• vespa/config-model/src/ — application model -> config instances.
• vespa/config/src/vespa/config/ — subscription/payload client code.
• vespa/configgen/src/ — config class generation.
• vespa/config-proxy/src/ — node-side proxy.

Open questions

• Which of the unmapped config-* modules belong in this MOC vs utility-libs
  (e.g. config-lib, configutil)?
• Confirm the deployment/provisioning story (config-provisioning, hosted-zone-api) —
  in scope for this MOC or the cloud-only area Code-map explicitly excludes?