openstack/fuel-specs
Code Issues Proposed changes
2e7d6b2855
fuel-specs/specs/6.1/refactor-l23-networking-api-ui.rst
Aleksey Kasatkin ba7ee4e972 Refactor Nailgun and UI to support native linux briges and bonds 
blueprint: support-linux-bridges-and-bonds-in-api-and-ui

Change-Id: I234dd222995b226ec0cea340837e5c437f1c705c
2015-03-05 12:43:22 +02:00

283 lines
9.5 KiB
ReStructuredText
Raw Blame History

..
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 <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.
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
View Git Blame Copy Permalink