union_replace_test - openconfig/featureprofiles GitHub Wiki
Perform a series of tests that validate the union_replace specification.
In depth tests for use of union_replace should reside within the features being tested.
-
Get the DUT configuriation in CLI format and store as
baseline_cfg. -
gNMI-3 should be a single _test.go file which contains a series of test functions which may be run in any order or individually.
Verify the same configuration as already on the device can be pushed and accepted without changing the configuration.
Steps Get baseline configuration Push configuration baseline + A to the DUT Get configuration A.1 Verify A.1 == baseline + A Push configuration baseline + A to the DUT Get configuration A.1 Verify A.1 == baseline + A
Generate an interface configuration and add that to the baseline configuration using union_replace. The interface should include description, MTU, and IP address.
- Get the baseline configuration (A).
- Generate a configuration with a new interface using OC (A.1).
- Push configuration A + A.1 to the DUT.
- Get configuration as A.2
- Verify A.2 == A + A.1
Repeat steps in gnmi-3.2.1 but use CLI for the added interface configuration.
Steps
- Get baseline configuration (B).
- Change the description of an interface using OC. (B.1)
- Push configuration baseline + B.1 to the DUT.
- Get configuration as B.2
- Verify B.2 == B + B.1
Steps
- Get baseline configuration (B).
- Generate OC configuration adding interfaces 1 and 2 (B.1).
- Push configuration baseline + B.1 to the DUT.
- Get configuration as B.2
- Verify B.2 == B + B.1
- Generate OC configuration adding only interface 1 (B.3).
- Push configuration baseline + B.3 to the DUT.
- Get configuration as B.4
- Verify B.4 == B + B.3
In some scenarios it is observed that moving a configuration from one interface to another can trigger bugs. Particularly if there is some conflicting element in the configuration such as an IP address. This test moves an IP address from interface 1 to interface 2 using union replace.
Interface configurations containing a mismatch with hardware (for example, due to a missing or incompatible transceiver module) must be accepted by a device. The interface with the mismatched configuration is expected to be in a down operational state as the result of such a configuration commit.
Steps
- Get configuration D.1 from DUT
- Generate a configuration D.2 with a port-speed mismatch in the OC which should be accepted by the device
- Push the configuration to the DUT
- Verify the gnmi.Set is accepted
- Get configuration D.3
- Verify D.2 == D.3. That is, verify only the interface speed is changed between D.1 and D.3. The remaining CLI and all OC must be unchanged.
Generate a configuration D.2 with a port-speed mismatch in the OC which should be accepted and applied by the DUT.
Generate a configuration D.2 with a port-speed mismatch in the CLI which should be accepted and applied by the DUT.
Verify a DUT rejects and rolls back a gnmi.Set union_replace with an invalid configuration in origin CLI and origin OC. Verify the original configuration is preserved.
Simple issues like a value out of range or referencing a policy that doesn’t exist in the OC case will be caught with a validation of the structs. Such an error is likely a different code path in a DUT vs. processing a configuration that validates but has some semantic error.
This test uses a configuration containing an invalid interface.
Steps used for 3.7.1 and 3.7.2:
- Get configuration E.1 from DUT.
- Generate a configuration E.2 which includes invalid configuration (see sub tests).
- Push the configuration E.1 + E.2 to the DUT.
- Confirm the DUT rejects the gnmi.Set.
- Get configuration E.3 from DUT.
- Verify E.1 == E.3 (the configuration is unchanged).
The invalid configuration is configuring MTU for non-existant interface in OC.
The invalid configuration is configuring MTU for non-existant interface in CLI.
This test verifies union_replace option 1 or 2 behavior for resolving overlapping configuration items between OC and CLI. Generate the following configuration item combinations which have overlaps between CLI and OC.
For NOS which implement option 1, the DUT should return a gRPC error of
INVALID_ARGUMENT. There must be no configuration changes applied.
For NOS with implement option 2, the configuration should be accepted, with the CLI value taking effect and the OC configuration leaf being accepted, but not applied as “state”.
Steps used for gnmi-3.8.1 and gnmi-3.8.2
- Get the CLI configuration E.1 from DUT.
- Generate a configuration E.2 which includes the overlapping configuration.
- Push the configuration E.1 + E.2 to the DUT.
- Confirm the DUT rejects the gnmi.Set with a gRPC error code of INVALID_ARGUMENT. Log the contents of the optional gRPC error string.
- Get configuration E.3 from DUT.
- Verify the configuration is as expected
- For option 1 NOS, verify E.1 == E.3 (the configuration is unchanged).
- For option 2 NOS, verify E.1 + E.2 == E.3 (the CLI config is updated, the OC state is updated to match the CLI value, the OC config is updated using the OC value. Note that the OC state leaves do not equal the OC config leaves)
Test where the configuration overlap is the interface MTU with two different MTU values.
Test where the configuration overlap is the interface MTU with the same MTU values.
Test where the configuration overlap is /network-instances/network-instance/protocols/protocol/bgp/global/config/as
Test where the overlap is
/routing-policy/policy-definitions/policy-definition/config/name.
These configurations should be accepted and applied successfully by the DUT.
Steps
- Get configuration D.1 from DUT Generate a configuration D.2 with one interface description set in CLI and a second set using OC.
- Push the configuration to the DUT
- Verify the gnmi.Set is accepted
- Get configuration D.3
- Verify OC configuration for interface one and two match the descriptions provided by the CLI and OC respectively.
Configure an interface with a missing transceiver module. The interface with the missing transceiver is expected to contain “config” leaves with the desired values. The “state” leaves should show a down operational state as the result of the configuration commit.
Steps
- Identify an interface without a transceiver module installed.
- Get configuration D.1 from DUT
- Generate a configuration D.2 , including a port-speed and breakout mode for the interface without a transceiver.
- Push the configuration to the DUT
- Verify the gnmi.Set is accepted
- Get configuration D.3
- Verify D.2 == D.3 configuration. That is, verify the “config” leaves for breakout mode and port speed are set to the target values. Verify the state for the interface is oper-state DOWN. All other CLI and OC config leaves must be unchanged.
Perform the steps where a configuration D.2 where the port-speed and breakout set using OC.
Perform the steps where a configuration D.2 where the port-speed and breakout set using CLI.
{
"components": {
"component": [
{
"config": {
"name": "Port0"
},
"name": "Port0",
"port": {
"breakout-mode": {
"groups": {
"group": [
{
"config": {
"breakout-speed": "SPEED_50GB",
"index": 1,
"num-breakouts": 2,
"num-physical-channels": 2
},
"index": 1
}
]
}
}
}
},
{
"config": {
"name": "Port0-Transceiver"
},
"name": "Port0-Transceiver",
"state": {
"parent": "Port0",
"type": "TRANSCEIVER"
},
"transceiver": {
"state": {
"form-factor": "QSFP28"
}
}
}
]
},
"interfaces": {
"interface": [
{
"config": {
"description": "First 50G breakout",
"name": "eth0/0"
},
"ethernet": {
"config": {
"port-speed": "SPEED_50GB"
}
},
"name": "eth0/0"
},
{
"config": {
"description": "Second 50G breakout with wrong port-speed",
"name": "eth0/1"
},
"ethernet": {
"config": {
"port-speed": "SPEED_100GB"
}
},
"name": "eth0/1"
}
]
}
}paths:
/interfaces/interface/ethernet/config/port-speed:
/interfaces/interface/ethernet/state/port-speed:
rpcs:
gnmi:
gNMI.Set:
union_replace: true
gNMI.Get:
gNMI.Subscribe:vRX