sysconfig only applies subnet/route config to physical interfaces

[Ryan Harper]

cloud-init master

Testing bridging configuration. First, empty subnets break sysconfig rendering; this has been reported in other bugs), after that, the resulting ifcfg-br0 does not include the static network configuration. Upon closer examination the _render_interface_subnets and routes is only called in the _render_physical_interface code. Instead, this should be called on *any* interface as we can configure subnets and routes on vlans or bridges, bonds, etc.

% cat bridge.yaml
network:
    version: 1
    config:
        - type: physical
          name: eth0
          mac_address: "52:54:00:12:34:00"
          subnets:
              - type: dhcp4
        - type: physical
          name: eth1
          mac_address: "52:54:00:12:34:02"
        - type: physical
          name: eth2
          mac_address: "52:54:00:12:34:04"
        - type: bridge
          name: br0
          bridge_interfaces:
            - eth1
            - eth2
          params:
              bridge_ageing: 250
              bridge_bridgeprio: 22
              bridge_fd: 1
              bridge_gcint: 2
              bridge_hello: 1
              bridge_maxage: 10
              bridge_maxwait: 0
              bridge_pathcost:
                - eth1 50
                - eth2 75
              bridge_portprio:
                - eth1 28
                - eth2 14
              bridge_stp: 'off'
              bridge_waitport:
                - 1 eth1
                - 2 eth2
          subnets:
              - type: static
                address: 192.168.14.2/24

After fixing the empty subnet issue, we can see in net-convert rendering of ifcfg-br0 is missing
the 192.168.14.2/24 address.

% cat target-sysconfig/etc/sysconfig/network-scripts/ifcfg-br0
# Created by cloud-init on instance boot automatically, do not edit.
#
AGEING=250
BOOTPROTO=none
DEVICE=br0
NM_CONTROLLED=no
ONBOOT=yes
PRIO=22
STP=off
TYPE=Bridge
USERCTL=no

[Scott Moser (smoser)]

This bug is believed to be fixed in cloud-init in 17.1. If this is still a problem for you, please make a comment and set the state back to New

Thank you.

[James Falcon (falcojr)]

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/2915