Ignition can't fetch remote resources on DigitalOcean

[bgilbert]

Issue Report

Bug

Container Linux Version

$ cat /etc/os-release
NAME="Container Linux by CoreOS"
ID=coreos
VERSION=1562.1.0
VERSION_ID=1562.1.0
BUILD_ID=2017-10-12-0536
PRETTY_NAME="Container Linux by CoreOS 1562.1.0 (Ladybug)"
ANSI_COLOR="38;5;75"
HOME_URL="https://coreos.com/"
BUG_REPORT_URL="https://issues.coreos.com"
COREOS_BOARD="amd64-usr"

Environment

DigitalOcean

Expected Behavior

Files can be fetched from remote URLs.

Actual Behavior

Ignition hangs indefinitely when fetching files from remote URLs.

Reproduction Steps

1. Boot an Ignition config on DO that references a remote file.

Other Information

When Ignition runs on DO, the system has only a link-local address for accessing the metadata server. coreos-metadata writes network units with static IPs obtained from the metadata server, but only to /sysroot, so they aren't used in the initramfs.

[crawford]

While this is definitely unfortunate, I'm not sure this is something we can/should fix. The root of the issue is that DigitalOcean still does not support DHCP in all of their regions. As a result, we have this hack in the initramfs which populates the lease info from their metadata service. In order to address the original issue, we would need a way to reconfigure the network after it has initially been set up. I would much rather DigitalOcean adopt DHCP.

[bgilbert]

Bit of a hack, but: couldn't we run coreos-metadata a second time to populate the initramfs' /run/systemd/network, then kill systemd-networkd on a signal that will cause systemd to restart it?

[crawford]

I'm not sure that's sufficient. I seem to recall the need to remove the link-local address, but that may have been unrelated. I can't remember.

[bgilbert]

Relevant kola tests disabled in coreos/mantle#807; reenable when fixed.

[bgilbert]

Thank you for reporting this issue. Unfortunately, we don't think we'll end up addressing it in Container Linux.

We're now working on Fedora CoreOS, the successor to Container Linux, and we expect most major development to occur there instead. Meanwhile, Container Linux will be fully maintained into 2020 but won't see many new features. We appreciate your taking the time to report this issue and we're sorry that we won't be able to address it.