by polvi on 4/12/16, 10:39 PM with 55 comments
by brandonbloom on 4/13/16, 12:41 AM
by darren0 on 4/13/16, 1:18 AM
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't required knowledge), so that adds two steps to users learning/using CoreOS.
by _0w8t on 4/13/16, 10:10 AM
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/delete/add, I have to have my own copy of the original file with my changes resulting in painful merge when the original is updated.
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/files.
by HorizonXP on 4/13/16, 12:17 AM
My biggest issue so far is CoreOS' 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.
I'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.
If I could have predictable interface names using Ignition, then I'm set!
by dghubble on 4/19/16, 8:41 AM
by songgao on 4/13/16, 6:08 AM
by rdtsc on 4/13/16, 3:29 AM
I think this looks like a slight jab at systemd ;-)
Systemd thinks it does a lot more other things best