leigh capili

+1 This would a great feature to support for all of our informational commands. In the meantime here's a jq solution that might be helpful for somebody: ```shell ignite ps...

Also applies to `ignite vm ls`

@dit7ya while there are technical limitations for this right now. Here are some options you could explore: You could create an ext4 loopback device with losetup that contains a copy...

If you add a systemd unit file to the proper directory within the Docker container, it will start your service on boot. This is the case for most packages you...

Our builds are fairly plain, so existing kernel-headers for the same major version would likely be operable, but it's not ideal to pretend to rely on that. A symlink can...

This is how to build the raw header files: https://unix.stackexchange.com/a/424982 This is how to produce the apt/deb pkgs: https://stackoverflow.com/a/19497460/5957101 We would modify our `ignite/images/kernel/` build to produce these artifacts.

Some defaults and values that could be configurable: ```yaml - runtime - sandbox.image - network-plugin - CNI bin dir - CNI conf dir - CNI subnet - CNI options -...

Just brainstorming: ```shell ignited daemon --config production-config.yaml ``` ```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:...

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...

Thanks for reporting. This is probably a bug. We should write an e2e test and see when it was introduced.