Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ignition: A new CoreOS machine provisioning utility

coreos.com

Post reply on HN
Print view View original

41–50 of 57 posts

Re: Ignition: A new CoreOS machine provisioning utility

#41

Post by seanp2k2 »

e12e wrote: post #30
otterley wrote: post #14

Earlier quoted context omitted.

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.

There's that, or: "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 JS…

The idea that one would install node + npm + some linter + linter configs + some method of automatically running the linter against the config before sending it to the thing being configured seems pretty insane and unnecessary to me. At the end of the day, it can suck, but being able to look at a config on a running system with inline comments makes debugging infra problems much easier. What the heck was wrong with # comments and the types of configs Apache et al. Have been using for decades?

Re: Ignition: A new CoreOS machine provisioning utility

#42

Post by seanp2k2 »

chrissnell wrote: post #33
darren0 wrote: post #9

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. 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 compiler. So now you have another language which compiles into JSON. So now there at least 2 problems, more if we want to be able to edit these configs on the systems directly, since we'll need some kind of tool chain.

Why do we keep re-inventing this wheel over and over again? Very plain text configs have worked for decades.

Re: Ignition: A new CoreOS machine provisioning utility

#43

Post by seanp2k2 »

nikolay wrote: post #10
darren0 wrote: post #9

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

Again here, now you have 2 problems. Why not just go with a simpler config language and skip converting it and all the complexity that adds? It's possible to make this extremely complex, to the point where the config is in a database with ACLs and requires a DB server system (which itself requires config) to host (e.g. WebLogic) , but what do you gain?

Re: Ignition: A new CoreOS machine provisioning utility

#44

Post by otterley »

seanp2k2 wrote: post #41
e12e wrote: post #30

Earlier quoted context omitted.

There's that, or: "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 JS…

The idea that one would install node + npm + some linter + linter configs + some method of automatically running the linter against the config before sending it to the thing being configured seems pretty insane and unnecessary to me. At the end of the day, it can suck, but being able to look at a config on a running system with inline comments makes debugging infra problems much easier. What the heck was wrong with #…

Nothing, but then you get to write your own parser for whatever bespoke configuration DSL you want to implement. Some people would rather focus on other aspects of functionality.

Re: Ignition: A new CoreOS machine provisioning utility

#46

Post by _0w8t »

JSON is not language that "makes it very easy to write tools to generate new configs or manipulate existing ones". 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.

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.

Re: Ignition: A new CoreOS machine provisioning utility

#47

Post by techdragon »

benley wrote: post #37
Sanddancer wrote: post #12

Earlier 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…

What I hate is that good tools for this like UCL go ignored or forgotten while JSON formats grow like weeds, and even excellent people like Hashicorp wind up contributing to this serious problem.

Re: Ignition: A new CoreOS machine provisioning utility

#48

Post by lsaferite »

geofft wrote: post #26
Sanddancer wrote: post #12

Earlier 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…

> There seems to be a pervasive undercurrent that if it looks website-ish, it's got to be good. 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?

Doesn't YAML fill the same slot, allow comments, and allow much saner human interaction? And as a bonus it's 100% (?) convertible to JSON (minus comments of course)

Re: Ignition: A new CoreOS machine provisioning utility

#49

Post by geofft »

lsaferite wrote: post #48
geofft wrote: post #26

Earlier quoted context omitted.

> There seems to be a pervasive undercurrent that if it looks website-ish, it's got to be good. 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?

Doesn't YAML fill the same slot, allow comments, and allow much saner human interaction? And as a bonus it's 100% (?) convertible to JSON (minus comments of course)

You'd have to add a validator to disallow some of the weirder YAML syntaxes. And once you have such a validator, you have neither JSON (it won't parse) nor YAML (it's dangerous to parse the file as YAML without running it through the validator first).

Re: Ignition: A new CoreOS machine provisioning utility

#50

Post by robszumski »

chrissnell wrote: post #33
darren0 wrote: post #9

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

Check out bootcfg, a server that sends out customized cloud config or ignition files based on mac address, IP, serial number, etc

https://github.com/coreos/coreos-baremetal#bootcfg

Post reply on HN