ipv6 static routes dropped when rendering opensuse files

Bug #1818661 reported by raphael.glon
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
cloud-init
Expired
Medium
Unassigned

Bug Description

Ipv6 static routes seem dropped during opensuse file generation

Information to quickly reproduce:

source .tox/py3/bin/activate
nosetests -s tests/unittests/test_net.py:TestOpenSuseSysConfigRendering.test_bond_config

-> this unittest is currently ok but here is what seems weird:

The related cloud init config tested in this unit test is (quoted from master:tests/unittests/test_net.py, slightly amended: I put the routes where I think they should be, but the rendered files are the same in the upstream master case anyway):

"""
version: 1
config:
  - type: physical
    name: bond0s0
    mac_address: "aa:bb:cc:dd:e8:00"
  - type: physical
    name: bond0s1
    mac_address: "aa:bb:cc:dd:e8:01"
  - type: bond
    name: bond0
    mac_address: "aa:bb:cc:dd:e8:ff"
    mtu: 9000
    bond_interfaces:
      - bond0s0
      - bond0s1
    params:
      bond-mode: active-backup
      bond_miimon: 100
      bond-xmit-hash-policy: "layer3+4"
    subnets:
      - type: static
        address: 192.168.0.2/24
        gateway: 192.168.0.1
        routes:
         - gateway: 192.168.0.3
           netmask: 255.255.255.0
           network: 10.1.3.0
      - type: static
        address: 192.168.1.2/24
      - type: static
        address: 2001:1::1/92
        routes:
         - gateway: 2001:67c:1562:1
           network: 2001:67c:1
           netmask: ffff:ffff:0
         - gateway: 3001:67c:1562:1
           network: 3001:67c:1
           netmask: ffff:ffff:0
           metric: 10000
"""

Rendered files:
"""
/etc/udev/rules.d/70-persistent-net.rules
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="aa:bb:cc:dd:e8:00", NAME="bond0s0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="aa:bb:cc:dd:e8:01", NAME="bond0s1"

/etc/sysconfig/network/ifcfg-bond0s1
# Created by cloud-init on instance boot automatically, do not edit.
#
BOOTPROTO=none
DEVICE=bond0s1
HWADDR=aa:bb:cc:dd:e8:01
MASTER=bond0
NM_CONTROLLED=no
ONBOOT=yes
SLAVE=yes
STARTMODE=auto
TYPE=Ethernet
USERCTL=no

/etc/sysconfig/network/ifcfg-bond0
# Created by cloud-init on instance boot automatically, do not edit.
#
BONDING_MASTER=yes
BONDING_OPTS="mode=active-backup xmit_hash_policy=layer3+4 miimon=100"
BONDING_SLAVE0=bond0s0
BONDING_SLAVE1=bond0s1
BOOTPROTO=none
DEFROUTE=yes
DEVICE=bond0
GATEWAY=192.168.0.1
IPADDR=192.168.0.2
IPADDR1=192.168.1.2
IPV6ADDR=2001:1::1/92
IPV6INIT=yes
MACADDR=aa:bb:cc:dd:e8:ff
MTU=9000
NETMASK=255.255.255.0
NETMASK1=255.255.255.0
NM_CONTROLLED=no
ONBOOT=yes
STARTMODE=auto
TYPE=Bond
USERCTL=no

/etc/sysconfig/network/ifroute-bond0
# Created by cloud-init on instance boot automatically, do not edit.
#
ADDRESS0=10.1.3.0
GATEWAY0=192.168.0.3
NETMASK0=255.255.255.0

/etc/sysconfig/network/ifcfg-bond0s0
# Created by cloud-init on instance boot automatically, do not edit.
#
BOOTPROTO=none
DEVICE=bond0s0
HWADDR=aa:bb:cc:dd:e8:00
MASTER=bond0
NM_CONTROLLED=no
ONBOOT=yes
SLAVE=yes
STARTMODE=auto
TYPE=Ethernet
USERCTL=no
"""

So we can see that static ipv6 routes are nowhere to be found in rendered files. Unfortunately, I have no SUSE distribution at hand to tell precisely what the good behaviour should be but this looks like the routes got lost during processing

And the reason of this drop:

The destination file path is the same for ipv4 and ipv6 routes, for opensuse

opensuse.py:

'route_templates': {
                'ipv4': '%(base)s/network/ifroute-%(name)s',
                'ipv6': '%(base)s/network/ifroute-%(name)s',
            }

but from sysconfig.py:

def _render_sysconfig
[...]
when rendering routes:
if cpath not in contents:
    contents[cpath] = iface_cfg.routes.to_string(proto)

So ipv6 routes get skipped (ipv4 has already taken the ifroute slot in contents dict)

description: updated
Revision history for this message
Dan Watkins (oddbloke) wrote :

Hi Raphael,

Thanks for filing this bug! It's not entirely clear to me precisely what the current (bad) behaviour is, and what that behaviour should be. Could you give an example of the rendered file(s) which don't look correct currently, as well as what you believe they should look like? Once done, please move this bug back to New.

Thanks!

Dan

Changed in cloud-init:
status: New → Incomplete
Revision history for this message
raphael.glon (raphael-glon) wrote :

Ok, additional information provided (step to reproduce).

description: updated
Changed in cloud-init:
status: Incomplete → New
Revision history for this message
Dan Watkins (oddbloke) wrote :

Thanks Raphael!

Changed in cloud-init:
status: New → Triaged
importance: Undecided → Medium
Revision history for this message
James Falcon (falcojr) wrote :
Changed in cloud-init:
status: Triaged → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.