This is for supporting a pre-queued waited FlowMod batching. mef_eline initially implemented in the client level, later on of_multi_table, and now telemetry_int is also implementing it, since flow_manager already manages this, it should be the one centralizing it, reuse the code, and most importantly facilitate when it comes to ensuring that these flows won't be lost if the controller restarts while flows are being batched (especially if the client is doing it async and has already deleted the high level resource like an EVC). flow_manager saves the flows before sending them, which is typically fast, so it can also re-send via consistency check later on if any unexpected major disruption happens during this process.
Here's how the feature should behave:
If {"batch_interval": <int>, "batch_size": <int>}, is set in the payload, either via request or event, then it should batch accordingly, if should be compatible with how the NApps using these two values in their settings values, but then they'll parametrize in the request/event. If batch_size is 0 or not set then it shouldn't batch. It should also follow the force: True flag, meaning, if force: False, it should not block the request.
The API spec will not be updated to v2, although it should, but it's not breaking compatibility, so let's still support this on v2, since we know that in the future, once more validations are addressed/implemented we'll bump v3, so let's leave to tag v3 in the future only.
Once this feature is available, new issues will be mapped for mef_eline, of_multi_table, telemetry_int
cc'ing @Alopalao, @Ktmi to be aware since I'll ask you guys to help with especifically with mef_eline and of_multi_table. We'll need this on 2023.2, although the priority is lower. I'll take care of this issue here on flow_manager and telemetry_int.
This is for supporting a pre-queued waited FlowMod batching.
mef_eline
initially implemented in the client level, later onof_multi_table
, and nowtelemetry_int
is also implementing it, sinceflow_manager
already manages this, it should be the one centralizing it, reuse the code, and most importantly facilitate when it comes to ensuring that these flows won't be lost if the controller restarts while flows are being batched (especially if the client is doing it async and has already deleted the high level resource like an EVC).flow_manager
saves the flows before sending them, which is typically fast, so it can also re-send via consistency check later on if any unexpected major disruption happens during this process.Here's how the feature should behave:
If
{"batch_interval": <int>, "batch_size": <int>}
, is set in the payload, either via request or event, then it should batch accordingly, if should be compatible with how the NApps using these two values in their settings values, but then they'll parametrize in the request/event. Ifbatch_size
is 0 or not set then it shouldn't batch. It should also follow theforce: True
flag, meaning, ifforce: False
, it should not block the request.The API spec will not be updated to v2, although it should, but it's not breaking compatibility, so let's still support this on v2, since we know that in the future, once more validations are addressed/implemented we'll bump v3, so let's leave to tag v3 in the future only.
Once this feature is available, new issues will be mapped for
mef_eline
,of_multi_table
,telemetry_int
cc'ing @Alopalao, @Ktmi to be aware since I'll ask you guys to help with especifically with
mef_eline
andof_multi_table
. We'll need this on2023.2
, although the priority is lower. I'll take care of this issue here onflow_manager
andtelemetry_int
.