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

11–20 of 57 posts

Re: Ignition: A new CoreOS machine provisioning utility

#11

Post by brandonbloom »

kkirsche wrote: post #8
brandonbloom wrote: post #7

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.

100% agreed. This is the reason I personally find YAML to be a great config alternative to JSON due to their ease of converting between the two

YAML isn't a particularly good config format either, since it has a lot of unnecessary complexity. For example, bare words are strings, but some bare words, such as "true" are booleans. Which wouldn't be so bad, but did you know that "yes" and "no" are also booleans? I've gotten YAML files from an i18n-system that screwed this up in a pretty bad way.

Re: Ignition: A new CoreOS machine provisioning utility

#12

Post by Sanddancer »

brandonbloom wrote: post #7

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.

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 makes it all that much harder to pull out the why part of settings does nothing to improve on that.

Re: Ignition: A new CoreOS machine provisioning utility

#14

Post by otterley »

brandonbloom wrote: post #7

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.

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.

Re: Ignition: A new CoreOS machine provisioning utility

#15

Post by otterley »

HorizonXP wrote: post #2

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

#16

Post by mintplant »

pm wrote: post #13
brandonbloom wrote: post #7

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?

TOML.

https://github.com/toml-lang/toml

Re: Ignition: A new CoreOS machine provisioning utility

#18

Post by wmf »

HorizonXP wrote: post #4
jsmthrowaway wrote: post #3

Earlier quoted context omitted.

> 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. That's a systemd decision, not CoreOS, and also impacts the 7.x series of RHEL derivatives and anything that uses systemd > v197, really. Your way is one of three to revert it. https://www.freedesktop.org/wiki/Softwar…

Ah, fair enough. But it looks like that introduces another problem. When you spin up a VM in ESXi, it generates a new MAC address for each interface. So it would be great to create systemd .network files that bind to those MAC addresses. Except you don't what MAC addresses you need to match against. The only flow I see working is: 1) Create a VM with your interfaces, but don't boot it. 2) Take the MAC addresses and e…

You don't have to match against MAC addresses, although there's virtually no documentation about how to do it any other way. In the pre-systemd past I've successfully created udev rules that match PCI slots so that the configuration does not depend on MAC addresses. It looks like the same thing should be possible (with trial and error) with path globbing in systemd.

Re: Ignition: A new CoreOS machine provisioning utility

#19

Post by jonaf »

kkirsche wrote: post #8
brandonbloom wrote: post #7

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.

100% agreed. This is the reason I personally find YAML to be a great config alternative to JSON due to their ease of converting between the two

In fact, YAML is a superset of JSON, and any valid JSON is also valid YAML. This becomes more obvious when you realize you can put any JSON objects inside of your YAML document and any YAML parser will correctly deserialize it.

Re: Ignition: A new CoreOS machine provisioning utility

#20

Post by rdtsc »

> 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

Post reply on HN