Configuration File v3

[mageddo]

Summary & Motivation

• After some features added, it's time to remodel and introduce a new version of the configuration file aiming a cleaner structure.
• Proposed configuration below
• Suggestions are welcome until: 2024-11-30

Goals

• Cleaner, easier to understand configuration file
• To create a structure object oriented like
• Propose a model which will be reflected to the YAML (Configuration using YAML #243) and Env (Feature Request: Dynamic generated env config #577) Configurations

Description

Blocks:

• Configuration using YAML #243
• Feature Request: Dynamic generated env config #577

Scope

• Remove dataprovider.vo.ConfigJson, it's not necessary anymore as we have config.Config domain object.
• Structure config.Config as proposed in section "New Modeling Propose"
• Model a "single" (using factory, strategy design pattern) parser which is capable to convert JSON, YAML and ENV configs to config.Config
  • The parser must be dynamic
• Only the terminal will stay with an dedicated mapper and receive new feature flags
• JSON v2 and The Legacy Env will remain supported, will have a dedicated mapper but won't receive new flags, only the JSON v3 will

New Modeling Propose

I'm proposing the following model, JSON Configuration example, the same will be made for YAML, etc.

{
  "version": 3,
  "server": {
    "dns": {
      "port": 53
    },
    "web": {
      "port": 5380
    },
    "protocol": "UDP_TCP",
    "noEntriesResponseCode": 3
  },
  "solver": {
    "remote": {
      "active": true,
      "dnsServers": [
        "8.8.8.8", "4.4.4.4:53"
      ],
      "circuitBreaker": {
        "name": "STATIC_THRESHOLD"
      }
    },
    "docker": {
      "registerContainerNames": false,
      "domain": "docker",
      "dpsNetwork": {
        "name": "dps",
        "autoCreate": false,
        "autoConnect": false
      },
      "networks": {
        "preferredNetworkNames": [
          "a", "b", "c"
        ]
      },
      "dockerDaemonUri": null
    },
    "system": {
      "hostMachineHostname": "host.docker",
      "hostMachineFallback": true
    },
    "local": {
      "activeEnv": "",
      "envs": [
        {
          "name": "",
          "hostnames": [
            {
              "type": "A",
              "hostname": "github.com",
              "ip": "192.168.0.1",
              "ttl": 255
            }
          ]
        }
      ]
    },
    "stub": {
      "domainName": "stub"
    }
  },
  "defaultDns": {
    "active": true,
    "resolvConf": {
      "paths": "/host/etc/systemd/resolved.conf,/host/etc/resolv.conf,/etc/systemd/resolved.conf,/etc/resolv.conf",
      "overrideNameServers": true
    }
  },
  "log": {
    "level": "DEBUG",
    "file": "console"
  }
}

[defung]

I love the grouping, makes the configs more readable!

Curious, does solver.docker.networks.preferredNetworkNames make my feature request redundant?

Also, what's solver.docker.dpsNetwork? Does it make DPS only resolve IPs from the dps network?

[mageddo]

Curious, does solver.docker.networks.preferredNetworkNames make #595 redundant?

I'm considering #595 will be already implemented when this feature get done.

Also, what's solver.docker.dpsNetwork? Does it make DPS only resolve IPs from the dps network?

DPS Network and DPS Network Auto Connect features