Earlier quoted context omitted.
[[ something ]]? No, thank you! Jsonnet [0], yes, please! [0]: http://jsonnet.org/
Why?
It's just weird syntax in my view.
Ignition: A new CoreOS machine provisioning utility
31–40 of 57 posts
Re: Ignition: A new CoreOS machine provisioning utility
#32Earlier quoted context omitted.
Any suggestions for a format that is sane?
Hashicorp has created HCL https://github.com/hashicorp/hcl
Which is based on UCL [0].
Re: Ignition: A new CoreOS machine provisioning utility
#33The 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. But why abandon the cloud-init format in general? Again, why would some…
I'm totally with you. We're big users of CoreOS and while there are aspects of cloud-init that I find janky, it's at least mostly easy to read and understand. The use of JSON is nuts. Just looking at the one-shots consolidated to a single line with \n's gives me a headache. This is moving forwards?
What I would prefer is a compiler. You feed it a directory of unit file drop-ins and app config templates and it builds a single artifact that can be served over HTTP and pulled by the server booting up. This could allow for dynamic configuration and automation but still makes it easy for the admin to piece the config together.
Re: Ignition: A new CoreOS machine provisioning utility
#34The 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. But why abandon the cloud-init format in general? Again, why would some…
YAML is good for simple configs. As the article says, JSON is much easier to programmatically generate than non-standard YAML. You still can store files in YAML, but compose and convert them into JSON in user data.
[deleted]
Re: Ignition: A new CoreOS machine provisioning utility
#35Apologies 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 just keep using XML, when the decision falls on my side.
- It supports comments;
- A very flexible format;
- I don't care it is verbose, it should be managed by tools anyway
- Can be automatically validated;
- Plenty of tools to choose from
Re: Ignition: A new CoreOS machine provisioning utility
#36Apologies 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?
I am going to be downvoted, but for me XML is sane and I don't bother to use anything else when given the option.
Re: Ignition: A new CoreOS machine provisioning utility
#37Apologies 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…
Honestly, I don't think JSON config files are a big problem. What's shitty is when humans are expected to manually create and edit plain JSON, but what's stopping us from using whatever tools we want to generate those JSON configs?
There are some very nice tools out there for this; I have taken to using jsonnet (http://jsonnet.org/), which is excellent as a configuration language. It's pretty comparable to Hashicorp's HCL, but it's a standalone thing.
Summary: Write your config files in a language of your choice. Render them to JSON for your apps to consume. Be thankful that every app doesn't have its own special snowflake config format like they used to.
Re: Ignition: A new CoreOS machine provisioning utility
#38Apologies 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?
Jsonnet is a really excellent one, imo: http://jsonnet.org/
There is also Flabbergast, which is comparable but a little less intuitive for those accustomed to Python-like languages: http://flabbergast.org/
The flabbergast homepage has a comparison table that covers most of the things mentioned in this thread: http://flabbergast.org/#comparison
Re: Ignition: A new CoreOS machine provisioning utility
#39Apologies 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?
This paper also pretty interesting: http://www.masella.name/~andre/2015-srecon-andre_masella.pdf
Re: Ignition: A new CoreOS machine provisioning utility
#40Earlier quoted context omitted.
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…
Honestly, I don't think JSON config files are a big problem. What's shitty is when humans are expected to manually create and edit plain JSON, but what's stopping us from using whatever tools we want to generate those JSON configs? There are some very nice tools out there for this; I have taken to using jsonnet ( http://jsonnet.org/ ), which is excellent as a configuration language. It's pretty comparable to Hashicor…
Ooh, they still do, especially things by Elastic.