Should update_config be used only for OTF (on the fly) changes

[rudranil-das]

These questions came up in a ixia-c internal discussion and following are thoughts that requires validation from model perspective.

a. How user is expected to use set_config and update_config when the constructs of two are same

• purpose of update_config is to have a quicker turn-around time for pushing configurations to traffic-engine, compared to set_config i.e. the traffic-engine can accommodate the changed items without stopping current execution of flows/devices which points to OTF changes from traffic-engine perspective.
• the configurations which can be applied OTF to traffic-engine should be allowed by controller implementation in update_config; rest should be prohibited through validation.

b. Should there be any change in model to identify/restrict non OTF applicable changes

• No, because OTF applicable changes would vary from one traffic-engine to other and should be taken care of in controller implementation.

c. Should there be both set_config(POST) and update_config (PATCH) or just set_config(POST) with an enum set/update

• this does not have as such implication on controller implementation
• current thought is yes, we need to keep both.

[rudranil-das]

@ankur-sheth @ajbalogh @ashutshkumr @arkajyoti-cloud

[ashutshkumr]

@winstonliu1111

[ajbalogh]

Some thoughts for discussion: update_config has not been implemented as there has been no specific ask. This is the first opportunity to fully specify the model specifics for this method. The intent is to update a config with only changes. The implementation should determine what changes should be applied as the patch content can be items that are being added, updated, or deleted.

[winstonliu1111]

i don't know the right solution to this. in general, update_config kinda distracts the message of "declarative state/configs", it sort of bring back imperative semantics back into config.

maybe we need to delineate based on: 1) if some kind of containers in the config need to be added/deleted (that should really be through set config, and controller should do its best to quickly detect diffs and apply the diff) 2) "actions/operations that you want to enact on a particular object or set of objects, or its properties. (think for example, changing rates of a stream dynamically is reasonable OTF change, and fit this category of (2).

maybe look at how openconfig delineates between gnmi and gnoi....maybe there is a parallel here for on the fly change on already set config?

[ajbalogh]

gnoi proto for bgp https://github.com/openconfig/gnoi/blob/master/bgp/bgp.proto

[ashutshkumr]

Per recent discussions, here are the three approaches:

PATCH /config

    {
        # reuse config and modify wherever needed
    }

POST /control/update_flow_rates

    {
        # new schema in models
        "flows": [
            {
                "name": f1
                # will only have rate, for size we'll need to have different schema
                "rate": {}
            },
            {
                "name": f1
                "rate": {}
            }
        ]
    }

PATCH /control/update_flows

    {
        # name of nodes to be updated
        "nodes": ["flow_rate", "flow_size"],
        # reuse config.flows
        "flows": [
            {
                "name": f1
                "rate": {},
                "size": {}
            },
            {
                "name": f1
                "rate": {},
                "size": {}
            }
        ]
    }

[ajbalogh]

I like POST /control/flows that gives an explicit options to update multiple flows/flow features in a single call. By changing 'nodes' into an array of update options and moving that into an update_flow schema object which would be contained in a list of update_flow schema objects it allows for asymmetric otf configuration. The POST /control/flows should also return the full config with the changes that have been submitted. This would be the running config that a user can hold onto as a snapshot for debug purposes. The components/schemas could possibly look like this:

proposed model

sample usage

```yaml paths: /control/flows: post: tags: ['Control'] operationId: update_flow_state requestBody: content: application/json: schema: $ref: '#/components/schemas/Flow.State' responses: '200': content: application/json: schema: $ref: '#/components/schemas/Config' components: schemas: Flow.State: description: A container for properties that define flow state changes type: object properties: update: description: Indicates what child nodes of a flow are being updated on the fly. type: array items: type: string enum: [rate, size] flow: $ref: '#/components/schemas/Flow' ```

```python sample code TBD ```

[ankur-sheth]

I took like PATCH /control/update_flows

[ankur-sheth]

@rudranil-das need to keep this open?

[rudranil-das]

Closed by PR#155