Ignition: A new CoreOS machine provisioning utility

Apologies for the somewhat off-topic remark, but ... Can we please stop creating new JSON-based config files? Sane config file formats must support comments.

The transition away from cloud-init and YAML is really quite odd to me. Nobody enjoys editing JSON files. Forgetting commas, no multi-line strings, no comments, escaping characters in strings, etc. Just reading the documentation of ignition should be enough to illustrate the pain it is to manage multiline content for unit files in an JSON string.<p>But why abandon the cloud-init format in general? Again, why would somebody want to learn a new configuration syntax. Using CoreOS already requires you to know and use systemd units (most other distros this really isn&#x27;t required knowledge), so that adds two steps to users learning&#x2F;using CoreOS.

JSON is not language that &quot;makes it very easy to write tools to generate new configs or manipulate existing ones&quot;. One cannot realistically consume JSON in a shell script, and even with tools that have native JSON support manipulating the config require the knowledge of document semantics as the language itself does not define how to combine or merge 2 documents into one.<p>For example, consider an application that comes with a complex JSON (or YAML as that language also share this shortcomings) that essentially describes default settings. I cannot just define an extra file that specifies a couple settings that I alter&#x2F;delete&#x2F;add, I have to have my own copy of the original file with my changes resulting in painful merge when the original is updated.<p>What I have found is that things like .ini files or config files in style of ssh_config work much better in practice. It is easy to generate and process them in any language with a notion of text IO including shell scripts and the merging functionality can be provided independent of semantics so I can keep config fragment outside the main file&#x2F;files.

Alex this looks great and likely addresses a lot of the problems I had with cloud-config. I was one of those with a Bash script that I used to generate multiple files, so this is great.<p>My biggest issue so far is CoreOS&#x27; naming of Ethernet interfaces on VMWare ESXi. It always uses some eno* name for each interface. I have a unique case where each VM I spin up has up to 10 interfaces.<p>I&#x27;ve solved this by adding net.ifnames=0 to my grub.cfg. It requires that I reboot the machine at least once to get it to take.<p>If I could have predictable interface names using Ignition, then I&#x27;m set!

Some useful Ignition configs can be found in the <a href="https:&#x2F;&#x2F;github.com&#x2F;coreos&#x2F;coreos-baremetal" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;coreos&#x2F;coreos-baremetal</a> examples. For those wondering about the format, they&#x27;re converted to JSON and served to machines.

I&#x27;m curious about how it works. I must be missing something, but if it runs before the network and file system are setup, how does it pull configure from a <a href="http:&#x2F;&#x2F;" rel="nofollow">http:&#x2F;&#x2F;</a> URL (say on bare metal) or oem:&#x2F;&#x2F; which is on FS? Does it run with a default setup for network&#x2F;fs and let systemd redo everything later?

&gt; Running before systemd helps ensure that all services established by Ignition are known to and can be managed by systemd when it subsequently starts. This allows systemd to do what it does best: concurrently start services as quickly as possible.<p>I think this looks like a slight jab at systemd ;-)<p>Systemd thinks it does a lot more other things best