Open luxas opened 5 years ago
Some defaults and values that could be configurable:
- runtime
- sandbox.image
- network-plugin
- CNI bin dir
- CNI conf dir
- CNI subnet
- CNI options
- CNI network name
- docker network name
- dns.nameservers[] (not implemented)
- dns.search[] (not implemented)
- ipv6 support (not implemented)
- vm.cpus
- vm.size
- vm.memory
- log-level
- kernel.image
- kernel.args
- gitops.repo-url
- gitops.branch / ref
- gitops.paths
These can be overridden by flags or the appropriate field in an Ignite VM API object.
Just brainstorming:
ignited daemon --config production-config.yaml
apiVersion: ignite.weave.works/v1alpha1
kind: Configuration
metadata:
name: production-config
spec:
logLevel: debug
runtime: docker
sandbox:
image: docker.io/weaveworks/ignite:0.6.4
networkPlugin: docker-bridge
dockerBridge:
network: testnet
cni:
binDir: /opt/cni/bin
confDir: /etc/cni/net.d
subnet: 10.39.0.0/18
networkName: prod-ignite-vm-bridge # should this be configurable?
confFile: 10-ignite.prod.conflist # should this be configurable?
# options:
dns:
# ipv6: true
nameservers:
- 1.1.1.1
- 9.9.9.9
search:
- deployment.example.com
- production.example.com
gitops:
repoURL: git@github.com/stealthybox/example
ref: master
paths:
- ignite/production-backend
- ignite/production-cache
kernel:
image: <something>
cmdLine:
- my
- default
- kernel
- args
vm:
cpus: 4
size: 20GB
memory: 4GB
For the ignite
tool since we do not yet have a complete daemon architecture, we could load this configuration file from some well known paths:
/etc/ignite/runtime.yaml
related XDG_CONFIG_HOME for root user?
Possibly this discussion is relevant to PR #428
I'd say this micro-VM data belongs in XDG_DATA_HOME: ~/.local/share/ignite
, and the XDG_CONFIG_HOME would contain the much simpler Ignite (not micro-VM)configuration defaults. Below is one possibility. Even better would be if we avoided configuration, preferring some defined, useful conventions, as discussed in issue #554, where this example can be avoided by adopting a convention discussed there:
manifest:
paths:
- /etc/firecracker/manifests
- /dfs/db/firecracker/manifests
- /dfs/sec/firecracker/manifests
- /home/me/.local/share/ignite/manifests
- /usr/local/share/ignite/manifests
- /usr/share/ignite/manifests
What configuration goes where?
XDG_CONFIG_HOME
: configuration that does not influence the specification/behavior of the micro-VM
XDG_DATA_HOME
: configuration that does influence the specification/behavior of the micro-VM
As
ignited
grows in complexity, instead of registering tons of flags on it, we'd use a declarative configuration file, aka. ComponentConfig, for it. (Could be even backed by git?)