Hi there all,

I am working through code/refactoring in cloud-init to enable translation of the network_data.json file[1] provided by openstack (via nova via neutron?) into the equivalent sysconfig files (ubuntu files should already *mostly* work and systemd files are underway as well).

Code for this sysconfig (WIP) is @ https://gist.github.com/harlowja/d63a36de0b405d83be9bd3222a5454a7 (requires base branch https://code.launchpad.net/~harlowja/cloud-init/cloud-init-net-refactor which did some tweaks to make things easier to work with).

Sadly there has been some questions around certain format conversion and what it means when certain formats are given, for example in the following example:

{
  "services": [
    {
      "type": "dns",
      "address": "172.19.0.12"
    }
  ],
  "networks": [
    {
      "network_id": "dacd568d-5be6-4786-91fe-750c374b78b4",
      "type": "ipv4",
      "netmask": "255.255.252.0",
      "link": "tap1a81968a-79",
      "routes": [
        {
          "netmask": "0.0.0.0",
          "network": "0.0.0.0",
          "gateway": "172.19.3.254"
        }
      ],
      "ip_address": "172.19.1.34",
      "id": "network0"
    }
  ],
  "links": [
    {
      "ethernet_mac_address": "fa:16:3e:ed:9a:59",
      "mtu": null,
      "type": "bridge",
      "id": "tap1a81968a-79",
      "vif_id": "1a81968a-797a-400f-8a80-567f997eb93f"
    }
  ]
}

In the cloud-init code what happens is that the links get connected to the networks and this gets then internally parsed, but for the bridge type listed here it appears information is missing about exactly what to bridge to (eth0, ethX? something else)?

Should the 'bridge' type just be ignored and it should just be treated as a physical device type (which will cause a different set of logic in cloud-init to apply); something else?

Thoughts would be appreciated,

[1] http://specs.openstack.org/openstack/nova-specs/specs/liberty/implemented/metadata-service-network-info.html#rest-api-impact

-Josh

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to