L23 networking refactoring in Nailgun/UI

https://blueprints.launchpad.net/fuel/+spec/support-linux-bridges-and-bonds-in-api-and-ui

Problem description

According to L23network module changes orchestrator input data will be changed significantly. This requires changes in Nailgun which allow convert networking information into new output data that is thrown to orchestrator.

This blueprint proposed following changes:

  1. implement network scheme for Nova-Network
  2. change default network provider to native linux bridges
  3. native linux bonding should be used instead of OVS bonds
  4. use linux bridges where possible
  5. refactor Multiple-Cluster-L2 part to address manifests changes
  6. provide additional parameters for NICs and bonds from API input to orchestrator, add parameters in UI
  7. remove networking-related hardcoded stuff from UI and describe it in fixture

Proposed change

implement network scheme for Nova-Network

Network configuration in case of Nova-Network is mostly hardcoded on library side. It is hard to maintain and develop. Network scheme should be implemented for configuring Nova-Network enabled environments the same way as it is done in case of Neutron now. This change will also allow support of bonding and other features in Nova-Network enabled configurations.

change default network provider to native linux bridges

Default L23 network provider is OVS now. OVS usage leads to a number of problems (e.g. with bonding) so library part will provide support for both native linux bridges (and bonds) and OVS objects. Nailgun should support ability to assemble network configuration based on native linux objects. It will use them by default. When networking is configured using UI, Nailgun will always use native linux bridges/bonds as default. User can setup networking using OVS objects via CLI (by uploading custom astute.yaml).

native linux bonding should be used instead of OVS bonds

The same way as linux bridges, native linux bonds will be used instead of OVS bonds. OVS bonds can be used with help of CLI (by uploading custom astute.yaml) Modes and parameters of linux bonds are different from OVS bonds so it should be taken into account. UI or API should provide proper lists of modes and parameters for bonds based on different providers. This part is very similar for both Neutron and Nova-Network.

use linux bridges where possible

Not all OVS objects can be substitutes with linux ones. Exceptions are Neutron/GRE, Neutron/VLAN, Neutron/floating subsystems, they have to use OVS. So, network scheme generated by Nailgun should carefully deal with these exceptions and properly connect objects of different type. One who make network setup with astute.yaml should be aware of this.

refactor Multiple-Cluster-L2 part to address manifests changes

Manifests are being rewritten is this part. So, Nailgun should address the changes. New scheme looks like:

endpoints:
  br-mgmt:
    IP:
      - 192.168.101.3/24
    routes:
      - net: 192.168.210.0/24
        via: 192.168.101.1
        metric: 10
      - net: 192.168.211.0/24
        via: 192.168.101.1
      - net: 192.168.212.0/24
        via: 192.168.101.1

Nailgun orchestrator serializer should calculate routes and pass them into orchestrator. This should be done when cluster have several node groups. Parameter via should be equal to network’s gateway now but it can be separate parameter later.

provide additional parameters for NICs and bonds from API input to orchestrator

There are two sets of parameters defined in for bonds and physical interfaces: bond_properties and interface_properties. Structures of these parameters are mostly defined for now but can be extended in future. UI will support changing of some part of them. On the first stage UI should provide possible values of parameters. Nailgun should provide default values where required. It is planned to acquire actual parameters from hardware and provide actual values via API on the next stage of feature implementation.

Parameters to be set in UI on the first stage.

bond_properties:
  mode: 802.3ad
  xmit_hash_policy: layer2
  lacp_rate: slow
  type__: linux

interface_properties:
  disable_offloading: true
  mtu: 9000

bond_properties field should be available for bonds only. It will exist in parallel with bond’s mode field. mode becomes optional in 6.1 but bond’s mode should be set either via bond_properties or via mode. type__ is not serialized for output to orchestrator. It indicates bond type in API, orchestrator uses different notation. Variables ended with __ will not be passed to orchestrator. UI should support only linux bonds (type__``=``linux) for 6.1 environments and only OVS bonds (type__``=``ovs) for 6.0 environments. xmit_hash_policy and lacp_rate are optional and are available for certain modes only.

interface_properties field should be available for both bonds and NICs. Bonded NICs will inherit properties from corresponding bond so their interface_properties will be omitted. There are default values here: disable_offloading``=``true and mtu``=``null, these values should come from backend.

Alternatives

Task 6 can be done separately. Other tasks should be done all together if current library changes will be done completely.

Data model impact

For task 3. New bonding modes and hash policies should be added for linux bridges. For task 6. Field interface_properties``(json type) should be added to NodeNICInterface and NodeBondInterface tables. Field ``bond_properties``(json type) should be added to NodeBondInterface table. ``flags field should be removed from NodeBondInterface table.

REST API impact

For task 3. New bonding modes and hash policies should be added for linux bridges. For task 6. Fields bond_properties (for bonds only) and interface_properties (for both bonds and NICs) should be available for GET/SET operations via “/nodes/x/interfaces/” handler.

Upgrade impact

For task 6. DB migration. For all tasks. Nailgun orchestrator serializer versioning. API will not have new handlers and no version increase to be made for current ones as this change does not lead to modification of current API data just adds new data.

Security impact

None

Notifications impact

None

Other end user impact

All new 6.1 deployments when configured via UI will have networking based on native linux bridges and bonding. Nova-Network enabled 6.1 deployments will support bonding.

Performance Impact

None

Other deployer impact

None

Developer impact

Most significant changes will be made in Nailgun orchestrator serializer. Its networking part for 6.1 will mostly be rewritten.

Implementation

Started.

Assignee(s)

Primary assignee:
Other contributors:
Testing:

Work Items

  • implement network scheme for Nova-Network. NG. (task 1)
  • change network scheme for Neutron to support linux bridges by default. NG. (tasks 2, 4)
  • use native linux bonding. NG, UI. (task 3)
  • refactor Multiple-Cluster-L2. NG. (task 5)
  • additional parameters for NICs and bonds. NG, UI. (task 6)
  • remove networking-related hardcoded stuff from UI. NG, UI (task 7)

Dependencies

L23network module refactoring (see references).

Testing

Same as for L23network module for tasks 1-5. It will require additional UI testing for tasks 6, 7.

Documentation Impact

The Documentation should be updated to explain the topologies and scenarios for Cloud Operators. It should also explain UI flow changes.