Config file

[tamasfe]

The CLI has a lot of options, especially if you include env var configuration, a lot of it could be moved to something like a mirrord.toml along with a --config cli flag for it.

[aviramha]

Thanks for the suggestion! We actually had it in mind - see discussion here #246
We're planning to work on this soon so would love to hear your ideas on how the config file should look (currently we're thinking JSON and not toml, but ofc in the end we can support both :))

[tamasfe]

but ofc in the end we can support both

I would prefer something that supports comments, but I agree, there should be no difficulty in supporting multiple formats. I would also add YAML to the mix as it's what kubernetes devs/operators are born with.

Some bikeshedding:

TOML

# The target selector.
# This can be used as a default, so people can just
# `mirrord exec whatever` during development.
[selector]
namespace = "foo-ns"
# Ideally wildcard support would be great here even in the CLI.
target = "pod/foo-1234-1234"

# Agent configuration.
[agent]
namespace = "foo-ns"
ttl = 30
ephemeral = false
log-level = "info"

# Each feature gets its own object instead of just `dns = true`
# in order to future proof it in case more options are added.
[feature]

[feature.fs]
enabled = false
read-write = true

[feature.network]
mode = "mirror"
# mode = "steal"

[feature.network.tcp]
enabled = true
outgoing = true

[feature.network.udp]
enabled = true
outgoing = true

[feature.network.dns]
enabled = false

# Environment variable configuration
[env]
# `-s` with wildcard support
include = ["FOO", "FOO_*"]

# `-x` with wildcard support
exclude = ["BAR", "BAR_*"]

# Target-specific overrides, the same keys are supported as above
# except for the selector.
# This should be merged with those if a target matches.
[target.'pod/bar-*'.env]

# I think this could completely override the existing list
# instead of merging it.
include = ["BAR_*"]

[target.'pod/bar-*'.feature.dns]
enabled = false

# ...

Same in JSON:

JSON

{
  "selector": {
    "namespace": "foo-ns",
    "target": "pod/foo-1234-1234"
  },
  "agent": {
    "namespace": "foo-ns",
    "ttl": 30,
    "ephemeral": false,
    "log-level": "info"
  },
  "feature": {
    "fs": {
      "enabled": false,
      "read-write": true
    },
    "network": {
      "mode": "mirror",
      "tcp": {
        "enabled": true,
        "outgoing": true
      },
      "udp": {
        "enabled": true,
        "outgoing": true
      },
      "dns": {
        "enabled": false
      }
    }
  },
  "env": {
    "include": [
      "FOO",
      "FOO_*"
    ],
    "exclude": [
      "BAR",
      "BAR_*"
    ]
  },
  "target": {
    "pod/bar-*": {
      "env": {
        "include": [
          "BAR_*"
        ]
      },
      "feature": {
        "dns": {
          "enabled": false
        }
      }
    }
  }
}

I included the selector idea from #392, with that specifying overrides for specific pods is rather trivial as it's just a wildcard match.

I would not use clap's built-in feature for the config file, I imagine there can be settings that are too complex to be represented as a flag in the CLI (the overrides as example).

[aviramha]

but ofc in the end we can support both

I would prefer something that supports comments, but I agree, there should be no difficulty in supporting multiple formats. I would also add YAML to the mix as it's what kubernetes devs/operators are born with.

Some bikeshedding:
TOML

Same in JSON:
JSON

I included the selector idea from #392, with that specifying overrides for specific pods is rather trivial as it's just a wildcard match.

I would not use clap's built-in feature for the config file, I imagine there can be settings that are too complex to be represented as a flag in the CLI (the overrides as example).

Awesome! I think that's the next feature we'll add to mirrord. Thank you so much.