Better Support for Multiple Networks in nova-network

Better Support for Multiple Networks in nova-network

https://blueprints.launchpad.net/nova/+spec/better-support-for-multiple-networks

Since nova-network is staying around, it needs a few updates for multiple networks. There are various settings that are automatically determined or set via flags, that should be explicitly set per network. This spec is about adding a few options to the networks table and converting the network manager and linux_net code to support multiple networks.

Problem description

Currently it is impossible to have multiple networks with different mtu settings or to have some networks that share ips or have external gateways and others that do not. If you have a single network it is possible to specify a different (external) gateway for that network by adding a custom dnsmasq.conf, but this breaks down when you have multiple networks.

Proposed change

This change proposes adding four fields to the networks table:

  • mtu

  • dhcp_server

  • enable_dhcp

  • share_address

Each of the new fields will be used in place of existing config options or automatic value interpretation. The defaults for these options will mean there is no difference to users if they are not specified.

It will also modify network create to allow these fields to be modified. An api extension will be added so one can determine if extra network fields are available.

Alternatives

Supporting this functionality without changing the data model would require some pretty complex config options. For example mtu could be a list of network names and mtus, but this is extremely unweildy.

Data model impact

This adds four new fields to the network model. The fallback for these fields will use the existing config options and defaults. These config options will be marked deprecated but will still work by default.

The four new fields will be added to the object model, and they will be cut out for older versions.

REST API impact

The current network create api allows extra values to be passed in and they are silently ignored. In order to provide information about whether the new fields are supported, a dummy api extension will be created and the extra fields will only be accepted/returned if the api extension is enabled.

The json for a network create call would currently look like:

{
    "network": {
        "label": "new net 111",
        "cidr": "10.20.105.0/24",
        ...
    }
}

With the new fields it would support:

{
    "network": {
        "label": "new net 111",
        "cidr": "10.20.105.0/24"
        "mtu": 9000,
        "enable_dhcp": "true",
        "dhcp_server": "10.20.105.2",
        "share_address": true,
        ...
    }
}

These fields will also be returned in the show command:

{
    "network": {
        "bridge": "br100",
        "bridge_interface": "eth0",
        "broadcast": "10.0.0.7",
        "cidr": "10.0.0.0/29",
        "cidr_v6": null,
        "created_at": "2011-08-15T06:19:19.387525",
        "deleted": false,
        "deleted_at": null,
        "dhcp_start": "10.0.0.3",
        "dns1": null,
        "dns2": null,
        "gateway": "10.0.0.1",
        "gateway_v6": null,
        "host": "nsokolov-desktop",
        "id": "20c8acc0-f747-4d71-a389-46d078ebf047",
        "injected": false,
        "label": "mynet_0",
        "multi_host": false,
        "netmask": "255.255.255.248",
        "netmask_v6": null,
        "priority": null,
        "project_id": "1234",
        "rxtx_base": null,
        "updated_at": "2011-08-16T09:26:13.048257",
        "vlan": 100,
        "vpn_private_address": "10.0.0.2",
        "vpn_public_address": "127.0.0.1",
        "vpn_public_port": 1000,
        "mtu": 9000,
        "dhcp_server": "10.20.105.2",
        "enable_dhcp": true,
        "share_address": true
    }
}

Security impact

This change doesn’t have any security impact.

Notifications impact

This change doesn’t impact notifications.

Other end user impact

This change will also include a modification to python-novaclient network create to allow users to create networks specifying the additional fields.

Performance Impact

The performance impact of this change is negligible.

Other deployer impact

Deployers should start using the network fields in place of the config options, but there is no requirement for them to move right away.

Developer impact

This change should not affect developers.

Implementation

Assignee(s)

Primary assignee:

vishvananda

Other contributors:

None

Work Items

Nova code addtions Python-novaclient code addtions Tempest test additions

Dependencies

There are no new dependencies for this feature.

Testing

There are currently no tempest tests for the create network call. A test for create network including the new fields will be added. The internal modifications will be covered by unit tests.

Documentation Impact

The new additions to the network create call need to be documented.

References

None

Creative Commons Attribution 3.0 License

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.

nova-specs