Hi community,
I would like to share some notes related to new FRM before meeting. FRM was
completely rewritten (as FR-sync) for another project and since it comes with
better logic and some advantages there was an idea to put it in open-source
(boron). In the future it could replace actual FRM (after proper testing from
consumers of course). Related bugs:
5411 FRM Reconciliation (Synchronization, Mark&Sweep)
* unifying bug only, advantages in the related bugs
5574 Batch RPC flows/groups/meters in one remote call suitable for 3node
Cluster [merged]
* request to expose one batch RPC to spare remote calls from FRM
(add/remove/update of F/G/M)
* already used in new FR-sync
5575 New FRM client of Batch RPC [waiting for review]
* calculating diff between config changes (on startup and retry between
config & operational)
* state compression for new config changes (while writing to the switch, on
per switch granularity)
* support for batched changes - as it is currently using batch RPCs (actual
FRM uses incremental strategy, thinking about making this strategy switchable)
* consistent pushing of dependent G/F/M (order and automatic barriers
between dependent objects)
* in order to stay consistent, new FRM listens to whole node and decides
the order of changes when pushing to device (changes have to be written
atomically within one node)
* faster operations as the barrier usage can be optimized and still
provide valid RPC outcome for all changes
* possibility to strict config enforcement (config flag)
* if set, all changes made on device which are not in config will be
removed
* default set to false = same behavior as current FRM
5577 New FRM RETRY mechanism for RCP call [in progress]
* related to possible fail of synchronization
* when there are more config changes in a row during short time, calulated
diff could be invalid (it takes some time before the changes appear on device)
and synchronization will fail
* in this case retry mechanism should start: 1. stop sending new config
changes, only update compress queue 2. elicit/wait for fresh operational,
calculate diff between actual config and fresh operational 3. retry syncup
(testing?)
5578 Improve new FRM speed/performance
* search for bottleneck, analyze thread pool size
* cleaning code and possible bug fixing
comments/questions appreciated
-al-
________________________________
From: [email protected]
<[email protected]> on behalf of Abhijit
Kumbhare <[email protected]>
Sent: Wednesday, May 11, 2016 6:09 PM
To: [email protected]
Subject: [openflowplugin-dev] Some topics for the May 16 meeting
Please add to the list:
1. user-driven statistics collecting RPC
2. New FRM? Bugs 5411, 5578,5575 and 5577
_______________________________________________
openflowplugin-dev mailing list
[email protected]
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
