ff3a5d2341
This change updates the puppet resource generation logic for network
interfaces to suport dual-stack.
Change summary
==============
- Aliases / labels
Previously, each alias was associated to a specific network. Now,
since more than one address can be associated to the same network,
the aliases are also associated to addresses. The label name is
now :<network_id>-<address_id>. The network_id is 0 if there's no
network associated with the alias, that's the case for the base
interface config or for the cases where the address is not
associated to a network. The address_id is 0 if there's no address
associated with the alias, which is the case for the base config
and for when there's no static address associated to the network,
i.e. the method is DHCP.
- Static addresses
Previously, interfaces with more than one static addresses not
associated with pools would be assigned just the first one. Now,
an alias config is generated for each address.
- CentOS compatibility
All the code related to CentOS was removed.
- Duplex-direct mode
Duplex-direct systems must have DAD disabled for management and
cluster-host interfaces. The disable DAD command is now generated
only in the base interface config for all types of interfaces.
- Address pool names
The change assumes a new standard for address pool names, they will
be formed by the old names with the suffixes '-ipv4' or '-ipv6'.
For example: management-ipv4, management-ipv6. Since other systems
that rely on the previous standard are not yet upgraded to
dual-stack, the constant DUAL_STACK_COMPATIBILITY_MODE was
introduced to control resource generation and validation logic in a
way that assures compatibility. The constant and the conditionals
will be removed once the other modules are updated. The
conditionals were implemented more as a way to highlight which
parts of the code are affected and make the changes easier in the
future.
- Tests / DB Base
The base class for tests was updated to generate more consistent
database states. Mixins for dual-stack cases were also created.
- Tests / Interface
Most of the test functions in the class InterfaceTestCase caused
unnecessary updates to the database and the context. The class
was splitted in two, the first one containing the tests that only
need the basic database setup (controller, one interface
associated with the mgmt network), and the other one for the tests
that need different setups.
A new fixture was created to test multiple system configs (IPv4,
IPv6, dual-stack), which inspects in detail the generated
hieradata. The tests associated with the InterfaceHostV6TestCase
were moved to the new fixture, and new ones were introduced.
Test plan
=========
Online setup tests
------------------
System: STANDARD (2 Controllers, 2 Storages, 1 Worker)
Stack setups:
- Single stack IPv4
- Single stack IPv6
- Dual stack, primary IPv4
- Dual stack, primary IPv6
[PASS] TC1 - Online setup, regular ethernet
mgmt0 (Ethernet) -> PXEBOOT, MGMT, CLUSTER_HOST
[PASS] TC2 - Online setup, VLAN over ethernet
pxe0 (Ethernet) -> PXEBOOT
mgmt0 (VLAN over pxe0) -> MGMT, CLUSTER_HOST
[PASS] TC3 - Online setup, bondig
mgmt0 (Bond) -> PXEBOOT, MGMT, CLUSTER_HOST
[PASS] TC4 - Online setup, VLAN over bonding
pxe0 (Bond) -> PXEBOOT
mgmt0 (VLAN over pxe0) -> MGMT, CLUSTER_HOST
Installation tests
------------------
Systems:
- AIO-SX
- AIO-DX
- Standard (2 Controllers, 2 Storages, 1 Worker)
[PASS] TC5 - Regular installation on VirtualBox, IPv4
[PASS] TC6 - Regular installation on VirtualBox, IPv6
Data interface tests
--------------------
System: AIO-DX
Setup:
data0 -> Ethernet, ipv4_mode=static, ipv6_mode=static
data1 -> VLAN on top of data0, ipv4_mode=static, ipv6_mode=static
For both interfaces, the following was performed:
[PASS] TC7 - Add static IPv4 address
[PASS] TC8 - Add static IPv6 address
[PASS] TC9 - Add IPv4 route
[PASS] TC10 - Add IPv6 route
[PASS] TC11 - Remove IPv4 route
[PASS] TC12 - Remove IPv6 route
[PASS] TC13 - Remove static IPv4 address
[PASS] TC14 - Remove static IPv6 address
Story: 2011027
Task: 49815
Change-Id: Ib9603cbd444b21aefbcd417780a12c079f3d0b0f
Signed-off-by: Lucas Ratusznei Fonseca <lucas.ratuszneifonseca@windriver.com>
|
||
|---|---|---|
| api-ref/source | ||
| config-gate | ||
| controllerconfig | ||
| devstack | ||
| doc | ||
| releasenotes | ||
| storageconfig | ||
| sysinv | ||
| tmp/patch-scripts/EXAMPLE_SYSINV/scripts | ||
| tools/docker/images | ||
| tsconfig | ||
| workerconfig | ||
| .gitignore | ||
| .gitreview | ||
| .yamllint | ||
| .zuul.yaml | ||
| CONTRIBUTORS.wrs | ||
| LICENSE | ||
| README.rst | ||
| bindep.txt | ||
| centos_build_layer.cfg | ||
| centos_dev_wheels.inc | ||
| centos_iso_image.inc | ||
| centos_pkg_dirs | ||
| centos_pkg_dirs_containers | ||
| centos_stable_wheels.inc | ||
| debian_build_layer.cfg | ||
| debian_iso_image.inc | ||
| debian_pkg_dirs | ||
| debian_stable_wheels.inc | ||
| test-requirements.txt | ||
| tox.ini | ||
README.rst
config
The starlingx/config repository handles the StarlingX configuration management services.
Its key component is the System Inventory Service (Sysinv), which provides the system command-line interface (CLI)1.
This repository is not intended to be developed standalone, but rather as part of the StarlingX Source System, which is defined by the StarlingX manifest2.