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>
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.
References
Description
Languages
Python
97.6%
Shell
2%
CSS
0.2%