.. This work is licensed under a Creative Commons Attribution 3.0 Unported License. http://creativecommons.org/licenses/by/3.0/legalcode ================================================================= 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: .. code-block:: yaml 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. .. code-block:: yaml 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 Other contributors: * Sergey Vasilenko * Vitaly Kramskikh * Stanislaw Bogatkin * Dmitry Ilyin * Stanislav Makar Testing: * Artem Panchenko * Yegor Kotko 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. References ========== * https://blueprints.launchpad.net/fuel/+spec/refactor-l23-linux-bridges * https://docs.google.com/a/mirantis.com/document/d/1QVoexrDF_MS92IZd4jnwPWQDxTAWMzUUrcMyu8VjGF4 * https://etherpad.openstack.org/p/network-schema-for-nova-network