Re: [openstack-dev] [nova][neutron][cloud-init] Questions around 'network_data.json'
On Tue, May 24, 2016 at 4:20 PM, Joshua Harlow 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 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][neutron][cloud-init] Questions around 'network_data.json'
I think there is an implementation error. The spec mentions that link type can be "vif", "phy" or (future) "bond". Nova passes the "raw" Neutron VIF type instead. IMO, "bridge" should be "vif" as per spec. -- Mathieu On Tue, May 24, 2016 at 5:20 PM, Joshua Harlow 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? > > 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova][neutron][cloud-init] Questions around 'network_data.json'
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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev