Network settings should be set in oem cloud-config.yml

[dsimunic]

The cloud-init option (-c) for bare metal install copies the cloud-init.yml into /var/lib/coreos-install/user_data. If one specified changes for network in that file (for example, writing out static.networking), those changes won't be executed until the next reboot, as user_data is parsed after the network.service started.

Looking at the boot journal, it appears that usr/share/oem/cloud-config.yml gets processed before the network.service is started, so this seems to be the right place for networking changes.

It is a minor annoyance, it would be great if at least the documentation mentions that.

[marineam]

Hm, cloudinit should restart networkd if it writes out any .network units.
Is this not happening? Also the fact that you see OEM being checked before
networkd starting is just chance, there isn't anything enforcing that
ordering and in fact cannot because some OEM scripts depend on networking
starting (but wait patiently for it to do so).
On Apr 28, 2014 1:43 AM, "dsimunic" notifications@github.com wrote:

The cloud-init option (-c) for bare metal install copies the
cloud-init.yml into /var/lib/coreos-install/user_data. If one specified
changes for network in that file (for example, writing out
static.networking), those changes won't be executed until the next
reboot, as user_data is parsed after the network.service started.

Looking at the boot journal, it appears that
usr/share/oem/cloud-config.yml gets processed before the network.service
is started, so this seems to be the right place for networking changes.

It is a minor annoyance, it would be great if at least the documentation
mentions that.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/11
.

[dsimunic]

I have just deleted /etc/systemd/network/static.network and rebooted the server. Couldn't reach the machine. Then I power-cycled the machine through the control panel, and now I can log in.

The boot log shows that static.network was written during the first boot, but then etcd and tlsdated were failing with unreachability errors for about five minutes until I rebooted, which rules out the possibility that a network service restart happened, right?

After the second reboot, the machine was reachable again, and DHCP didn't get applied on the interface statically configured through static.network so I guess the file was written during the first boot but didn't get applied, as in this gist from the log a few days ago, with the same symptoms. (Note how both files 2 and 3 lack DHCP on eno1, meaning that the service picked up static.network settings).

[crawford]

@dsimunic I haven't been able to reproduce this in my environment. Can you confirm whether or not this is still an issue?

[dsimunic]

@crawford yes, I did have this issue again setting up new servers two weeks ago. An extra reboot was required for machines to pick up static.network settings.

[crawford]

@dsimunic would you mind sharing your cloudconfig?

[dsimunic]

@crawford sure, here's one for the test machine:

    #cloud-config

    hostname: vpro    

    coreos:
        etcd:
            name: vpro
        units:
          - name: etcd.service
            command: start

    ssh_authorized_keys:
      - ssh-rsa ...

    write_files:
    -   content: |
            [Match]
            MACAddress=00:1c:c4:87:c5:2e

            [Network]
            Gateway=192.168.1.1
            Address=192.168.1.5/24
            DNS=8.8.8.8

        path: /etc/systemd/network/static.network

I'm on vacation until the 21st, so won't be able to test this again and share the boot log in case you can't repro it with the latest release.

[crawford]

Ah, as I suspected. Rather than adding static.network under write_files, put that under coreos.units. After writing out the unit, cloud-init will restart networkd causing it to load the new configuration. Since this was under write_files, cloud-init was unaware that it should restart networkd.

coreos:
  units:
  - name: static.network
    runtime: yes
    content: |
      [Match]
      MACAddress=00:1c:c4:87:c5:2e

      [Network]
      Gateway=192.168.1.1
      Address=192.168.1.5/24
      DNS=8.8.8.8

I'm going to close this for now (enjoy your vacation). Re-open it if you run into any other issues.

[dsimunic]

Thanks. Maybe it would be good to mention this in the docs. Current wording hints at using write_files as the way to do it (note the anchor on the link in the second paragraph), and that's where I picked it up from.

[crawford]

You are absolutely right. I'll fix that right now.

[dminkovsky]

+1. The thing is that .link and .network are not systemd units. Did I miss this in the docs? I've contributed to docs before, so if this hasn't been added (not finding), I will gladly add a sentence.

Thanks.

[dminkovsky]

And, and will this also restart udevd/netword if I write out a .link in coreos.units?

[crawford]

While they aren't technically systemd units, it makes sense to group them with the rest of the units.

If cloudinit encounters a .network, .netdev, or .link "unit", it will restart networkd after writing the file.

[dminkovsky]

Thanks for the clarification, @crawford. Could you please clarify one more thing:

I am trying to change my interface link name, with a .link unit that looks like this:

#cloud-config

hostname: core1
coreos:
    units:
    - name: net0.link
      runtime: yes
      content: |
        [Match]
        Driver=pcnet32

        [Link]
        Name=net0
        MACAddress=00:0c:29:e1:49:41

Will the networkd restart be sufficient to effect the desired change? I'm not seeing it, and not sure what I'm doing wrong. Then again, reboots aren't helping either, so I suspect it's my config.

Interestingly, it's writing the unit to be /run/ and /etc/