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.
Any suggestions for a format that is sane?
Ignition: A new CoreOS machine provisioning utility
21–30 of 57 posts
Re: Ignition: A new CoreOS machine provisioning utility
#22> 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. I think this looks like a slight jab at systemd ;-) Systemd thinks it does a lot more other things best
Re: Ignition: A new CoreOS machine provisioning utility
#23Alex 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. 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.if…
Why do you need predictable interface names if you're using DHCP?
Re: Ignition: A new CoreOS machine provisioning utility
#24Apologies for the somewhat off-topic remark, but ... Can we please stop creating new JSON-based config files? Sane config file formats must support comments.
Any suggestions for a format that is sane?
Re: Ignition: A new CoreOS machine provisioning utility
#25Re: Ignition: A new CoreOS machine provisioning utility
#26Apologies for the somewhat off-topic remark, but ... Can we please stop creating new JSON-based config files? Sane config file formats must support comments.
I wouldn't apologize for that, you're addressing the elephant in the room here. JSON has turned into the new XML. There seems to be a pervasive undercurrent that if it looks website-ish, it's got to be good. So it seems to be used quite a bit in lieu of looking carefully at the problem and figuring out the best structured format. Configuration files tend to have a lot of ambiguity in them, going to a format that make…
I don't get that from the article. There's a stated reason, that it's a stricter format with much less risk of type confusion, which sounds plausible enough to me. There's also the benefit that tool support is good. Why does the web need to be relevant at all?
Re: Ignition: A new CoreOS machine provisioning utility
#27> 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. I think this looks like a slight jab at systemd ;-) Systemd thinks it does a lot more other things best
I think that was poorly explained on their part. Digging deeper into the docs, it looks like Ignition writes unit files that systemd runs; e.g. networkd is still used to configure networking.
Re: Ignition: A new CoreOS machine provisioning utility
#28Re: Ignition: A new CoreOS machine provisioning utility
#29Re: Ignition: A new CoreOS machine provisioning utility
#30Apologies for the somewhat off-topic remark, but ... Can we please stop creating new JSON-based config files? Sane config file formats must support comments.
At long as an app isn't strictly validating the JSON, you should be able to add keys like { "comment": "this does xxx" } to a JSON configuration object.
"Comments in JSON
I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't.
Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser."
https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaG...