Clarification : Need a way for gNMI union-replace to handle the OC/CLI config dependency

[peichengATgit]

It is not clear how "union-replace" handles the OC/CLI dependency per the current writing.

Take bgp as the example,
some vendor may include bgp as its built-in functionality,
while others may include bgp as a conditional feature, and requires explicit activation.

Take below config snippet as the example.
The user would need to first apply "feature bgp" to enable the bgp feature,
only then "router bgp ..." become acceptable config.

feature bgp

router bgp 64500
   neighbor 10.1.1.14 remote-as 50

Commonly, the openconfig would define the bgp model tree, while missing out the conditional toggle.
In this example, assume only the "router bgp ..." part is defined in openconfig.

This is usually not a big deal, as people today can do two gnmi set, or one gnmi set with two update requests.

• the first request uses the native yang or cli to apply 'feature bgp'
• the second request uses the OC payload to config the router bgp and its neighbor.

However, in case of 'union-replace' https://github.com/openconfig/reference/blob/master/rpc/gnmi/gnmi-union_replace.md#531-union-behavior-for-cli-and-openconfig, the writing restricts the the network device

• there can be only one CLI payload
• has to first process OC then the CLI.

This is a chicken-egg issue which cannot really work,
as the OC processing requires the CLI to enable the feature, but the CLI can only be processed after OC.

We would need some clarification / writing to allow the flexibility for the network device to handle the dependency.
Something like the following :

- Create a candidate configuration using factory defaults.
 o Factory defaults are used because CLI is expected to represent the entire configuration, subject to any partitioning rules of bootz and gNSI.

<< If the OC path depends on specific proprietary CLI items,
     the network device may merge such specific CLI items to the candidate configuration.
     Such early merge only means to facilitate the OC processing, and shall not introduce the conflicts.

-  Process OC paths, replacing the relevant configuration items in the candidate configuration. This includes OC default values.
-  Process CLI items merging them to the candidate configuration. Generate an error if there is conflict between OC and CLI as defined below. Conflict and resolution is defined in [5.3.3](https://github.com/openconfig/reference/blob/master/rpc/gnmi/5.3.3-Resolving-issues-with-union-between-the-origins).

[LimeHat]

This is a chicken-egg issue which cannot really work,

No, that's not right. You build a singular candidate, then copy it to intended/running config as an atomic operation/commit.

It seems in your example you're either
a) trying to push OC to the intended/running first, and/or
b) don't have an ability to build a union of two origins and trying to work with completely independent candidates with strict validation

[peichengATgit]

The question is not about atomic commit,
but about incrementally building the candidate.

The "candidate configuration" tends to enforce multiple validation rules, at both the "per change" and "eventual commit" time.
Here, putting the OC payload into the candidate would trigger the "per change validation", and would not work if it has dependency on the CLI config, which does not exist yet in the candidate.

Likely you assume that the candidate can freely disable and enable the "per change" validation.

• <<< Disable candidate's validation. So can push in OC config without checking its dependency.
• Process OC paths, replacing the relevant configuration items in the candidate configuration. This includes OC default values.
• Process CLI items merging them to the candidate configuration. Generate an error if there is conflict between OC and CLI as defined below. Conflict and resolution is defined in 5.3.3.
• <<< Enable candidate's validation back to run against the final candidate. As long as the eventual OC+CLI satisfies the dependency, then it is good.

[robshakir]

gNMI doesn't have the idea of candidates. The transaction that is sent from the management system to the device is intended to be the completed change that is expected to validate + apply. So the logic you describe of "disable the candidate validation" is exactly what is expected -- in gNMI terms:

• receive a SetRequest
• foreach transaction in the SetRequest
  • if union_replace is not populated
    • process delete
    • process replace
    • process update
  • if union_replace is populated
    • follow rules for merging contents described in the spec
• apply any validations that are required on the post-operations tree
• return success/failure to the client

You cannot make a change via gNMI Set that does not get validated+applied.