no need to write systemd.link files

Bug #1594546 reported by Scott Moser on 2016-06-20
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
cloud-init
Medium
Unassigned

Bug Description

When fixing bug 1579130 , we made cloud-init rename devices itself,
rather than relying on the systemd.link files to do that.

cloud-init was still writing .link files like:
 /etc/systemd/network/50-cloud-init-ens2.link

That leads to just a confusing situation as cloud-init will trump
any renaming systemd does in all cases.

We'd like to get to a place where cloud-init allows the user to later customize
the name of the devices in a supported manner, but for the moment, these files
only create confusion.

Related Bugs:
 * bug 1579130: need to support renaming of devices in container and on first boot

Related branches

Scott Moser (smoser) on 2016-06-20
description: updated
Changed in cloud-init:
status: New → Confirmed
importance: Undecided → Medium
status: Confirmed → In Progress
Scott Moser (smoser) wrote :

This is fix-committed in trunk. at 1247.
it was marked as fixed in 1243, but now fixed.

Changed in cloud-init:
status: In Progress → Fix Committed
Scott Moser (smoser) wrote :

Hello,
An SRU upload of cloud-init for 16.04 that contains a fix for this bug has been made under bug 1595302. Please track that bug if you are interested.

Scott Moser (smoser) wrote :

This is fixed in cloud-init 0.7.7

Changed in cloud-init:
status: Fix Committed → Fix Released
Baodong (Robert) Li (baoli) wrote :

I'm still seeing this issue with
    cloud-init 0.7.9-113-g513e99e0-0ubuntu1~16.04.1

With the command:
 vconfig add ens3 add 2000

an interface with the name 'rename<ifno>@ens3' was added, however the interface would never come up. Systemd-udevd was trying to rename ens3.2000 to ens3 due to the systemd link file 50-cloud-init-ens3.link that was added by cloud-init.

I'm running a ubuntu xenial cloud image

No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.2 LTS
Release: 16.04
Codename: xenial

So basically it's Debian Distro. Checking the code in distros/debian.py,
    renderer_configs = {
        "eni": {"eni_path": network_conf_fn["eni"],
                "eni_header": ENI_HEADER}

        "netplan": {"netplan_path": network_conf_fn["netplan"],
                    "netplan_header": ENI_HEADER,
                    "postcmds": True}
    }

adding the following to the "eni" dict solved the issue:
               "links_path_prefix": None

Is this still a bug?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers