Ignition: A new CoreOS machine provisioning utility
1–10 of 57 posts
Re: Ignition: A new CoreOS machine provisioning utility
#2Alex 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.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!
Re: Ignition: A new CoreOS machine provisioning utility
#3Alex 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…
> 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/Software/systemd/Predictabl...
Re: Ignition: A new CoreOS machine provisioning utility
#4Alex 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…
> 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 enter them into your .network files, created via cloud-config/Ignition 3) Mount the cloud-config/Ignition file to your VM and boot
Which is a bit painful to do manually when you have 10 VMs, with 5-10 interfaces each. I'd love to automate this, and if you happen to have a suggestion here, I'd really appreciate it.
Edit: Oh, and when I said it had an eno* number, it's more like eno16777736, which is not very predictable at all.
Re: Ignition: A new CoreOS machine provisioning utility
#5Alex 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…
Are you talking about things like eno16777736 ? it's a vmware issue...
http://serverfault.com/questions/636621/why-is-my-eth0-calle...
Re: Ignition: A new CoreOS machine provisioning utility
#6Alex 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…
Are you talking about things like eno16777736 ? it's a vmware issue... http://serverfault.com/questions/636621/why-is-my-eth0-calle...
Yes, precisely. The comment below identified one of 3 possible routes to turn off the naming, one of which I'm using (net.ifnames=0 in the kernel config).
If I could find a better way to match the interfaces, it would be fantastic.
Re: Ignition: A new CoreOS machine provisioning utility
#7Apologies for the somewhat off-topic remark, but ... Can we please stop creating new JSON-based config files? Sane config file formats must support comments.
Re: Ignition: A new CoreOS machine provisioning utility
#8Apologies 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
Re: Ignition: A new CoreOS machine provisioning utility
#9The 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 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.
Re: Ignition: A new CoreOS machine provisioning utility
#10The 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.