blueprint: support-linux-bridges-and-bonds-in-api-and-ui Change-Id: I234dd222995b226ec0cea340837e5c437f1c705c
9.5 KiB
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:
- implement network scheme for Nova-Network
- change default network provider to native linux bridges
- native linux bonding should be used instead of OVS bonds
- use linux bridges where possible
- refactor Multiple-Cluster-L2 part to address manifests changes
- provide additional parameters for NICs and bonds from API input to orchestrator, add parameters in UI
- 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.
remove networking-related hardcoded stuff from UI and describe it in fixture
Now UI have some logic to determine whether bonding is available, hardcoded list of possible values for mode, hash policy, lacp rate, their interdependencies. This should be described using DSL or some other textual form and placed into fixture (preferably). Another problem is that the structure of networking configuration have fixed format and cannot be enhanced like environment settings. It should be converted to our DSL to provide the required flexibility.
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:
-
- Aleksey Kasatkin <akasatkin@mirantis.com>
- Other contributors:
-
- Sergey Vasilenko <svasilenko@mirantis.com>
- Vitaly Kramskikh <vkramskikh@mirantis.com>
- Stanislaw Bogatkin <sbogatkin@mirantis.com>
- Dmitry Ilyin <dilyin@mirantis.com>
- Stanislav Makar <smakar@mirantis.com>
- Testing:
-
- Artem Panchenko <apanchenko@mirantis.com>
- Yegor Kotko <ykotko@mirantis.com>
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.