[openstack-dev] [nova][neutron][cloud-init] Questions around 'network_data.json'

Ryan Harper ryan.harper at canonical.com
Tue May 24 21:31:01 UTC 2016


On Tue, May 24, 2016 at 4:20 PM, Joshua Harlow <harlowja at fastmail.com>
wrote:

> 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?
>

Thanks Josh,

In particular, I'm hoping to clarify that the spec is meant to describe
guest network configuration (be that a baremetal instance in Ironic or a
VM).  If that holds, then I think
exposing the compute node config (LinuxBridge in this case) into guest
network config is confusing, and instead the network_data.json should have
had type: vif or type: phys.

The same holds true for ovs setup's, we've seen this network_data.json:


http://paste.openstack.org/show/498749/

then ovs setups should emit type: vif  or type: phys to indicate a guest
'physical' interface.

Thanks,
Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160524/b9e7ec8c/attachment.html>


More information about the OpenStack-dev mailing list