Open Stack

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 <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?
>
> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev