Configdrive Network JSON

{
    "networks": [ // a network is attached to one link and contains a set of L3 configs, such as IP/netmask or whether to dhcp
        {
            "id": "servicenet", //required
            "type": "ipv4-static", //required
            "link": "servicenet_vlan", //required, single link
            "ip": "10.0.0.5",
            "gateway_ip": "10.0.0.1",
            "netmask": "255.255.0.0"
            "dns_nameservers": ["10.0.3.2"],
            "routes": [ ], // Should we explicitly list default route? I think gateway_ip covers it.
            
        },
        {
            "id": "pubnet", //required
            "type": "ipv6-static", //required
            "link": "bond0.101", //required, single link
            "ip": "52.0.0.5",
            "gateway_ip": "52.0.0.1",
            "netmask": "255.255.0.0"
            "routes": [
                {
                    "destination": "172.16.0.0/0",
                    "gateway_ip": "52.0.0.2",
                },
            ],
        },
        {
            "id": "dhcpnet", //required
            "type": "ipv4-dhcp", //required
            "link": "eth2", //required, single link
            "dhcp_hostname": "foo.bar.example.com"
        },
    ],
    "links": [ // links are L1/L2 devices, such as NICs, bonds, VLANs. 
        {
            "id": "servicenet_vlan", //required
            "type": "vlan", //required
            "vlan_link": "bond0",
            "vlan_id": 401,
            "neutron_port_id": "11111111-1111-1111-1111-111111111111"
            "vlan_link": "bond0" //single link for VLAN
        },
        {
            "id": "bond0", //required
            "type": "bond", //required
            "bond_links": [
                "eth0",
                "eth1"
            ], //required, a list of link ids
            "bond_type": "802.1ad" // required
        },
        {
            "id": "eth0", //required
            "type": "ethernet", //required
            "ethernet_mac_address": "aa:bb:cc:dd:ee:ff" //could be "ethernet_pci_path" instead
        },
        {
            "id": "eth1", //required
            "type": "ethernet", //required
            "ethernet_mac_address": "aa:bb:cc:dd:ee:fe"
        },
        {
            "id": "eth2", //required
            "type": "ethernet", //required
            "ethernet_mac_address": "aa:bb:cc:dd:ee:fd"
        },
    ]
}

Line 13 vs Line 17: gateway_ip vs nexthop, we should pick one name... Either gateway_ip or nexthop, but i suspect we should just always call it gateway_ip

Line 21 and Line 2:

1. "vlans": ["pubnet"] -- weird that this is an array. feels like it might just want to be a single string -- BUT see #2

2. If VLANs are DEVICES, then Line 22 should just be the string "pubnet".

Line 13, we specifically have a gateway.

Why don't we treat the default gateway as any other route in the host_routes:[] array?

Russell: Whoops that's what I meant to do.

I agree on the routes, and gateway_ip > nexthop. Those were from the nova-spec, so I'm going to -1 that to try to get a better structure.

So, I pulled VLAN out into its own top level key. My thought is that a port represents a network on a device, possibly with a VLAN. That device can be a combination of interfaces (bond, bridge, etc). Ports can share interfaces. You'd have a new port for each new VLAN. So you could have a port for pubnet and one for servicenet, both using "device": "bond0". Is that sensible?

My other thought was that a VLAN could have a device key. So ports have VLANs, VLANs are on devices, devices have interfaces. But if you don't have a VLAN this gets a bit weird. So I'm leaning towards the first way.

I am aiming to have something that could feasibly be the standard for Nova so we don't have some divergence down the road.

So the top level vlan key sort of makes sense other than is kind of sucks when you have to iterate over all the objects to find the one you are looking for (so maybe have the name be the key?)

It's also worth maybe abstracting 'vlan' out a bit. There's a few things that could feasibly go there (vlan, vxlan, whatever) and it might not make sense to call everything a vlan. Neutron abstracts this out into {'segmentation_id', 'network_type', and 'physcial_network'}, maybe you should make that match?

@morgabra Alright, fixed both. I left physical_network off for providers because it is specified in ports.