https://blueprints.launchpad.net/fuel/+spec/support-linux-bridges-and-bonds-in-api-and-ui
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:
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.
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).
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.
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.
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.
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.
Task 6 can be done separately. Other tasks should be done all together if current library changes will be done completely.
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.
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.
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.
None
None
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.
None
None
Most significant changes will be made in Nailgun orchestrator serializer. Its networking part for 6.1 will mostly be rewritten.
Started.
L23network module refactoring (see references).
Same as for L23network module for tasks 1-5. It will require additional UI testing for tasks 6, 7.
The Documentation should be updated to explain the topologies and scenarios for Cloud Operators. It should also explain UI flow changes.