Support ComponentConfig for configuring defaults

[luxas]

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?)

[stealthybox]

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.

[stealthybox]

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

[stealthybox]

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?

[bbros-dev]

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