Hi community,

I would like to share some info about new RPCs that I am currently 
implementing.  When implementing them, I was following assignment from Bug 5692 
from Bugzilla: https://bugs.opendaylight.org/show_bug.cgi?id=5692.

So, in short, these new RPCs will enable user-driven statistics collecting for 
all current statistics types:

    * /restconf/operations/opendaylight-direct-statistics:get-group-statistics
    * /restconf/operations/opendaylight-direct-statistics:get-meter-statistics
    * /restconf/operations/opendaylight-direct-statistics:get-flow-statistics
    * 
/restconf/operations/opendaylight-direct-statistics:get-node-connector-statistics
    * /restconf/operations/opendaylight-direct-statistics:get-queue-statistics

Each of these RPCs have optional flag "store-stats", what will also update 
DS/operational.
Also, when these RPCs are sent without any flags (not counting "node" and 
"store-stats" flag), it will return all statistics for specified type. For 
example, when someone will send "get-meter-statistics" without specifying 
"meter-id" flag, RPC output will be statistics for all meters on specifyied 
node.

Example for getting statistics for all groups for node "openflow:1" with flag 
to update DS/operational:

```
<input xmlns="urn:opendaylight:direct:statistics">
    <node 
xmlns:inv="urn:opendaylight:inventory">/inv:nodes/inv:node[inv:id="openflow:1"]</node>
    <store-stats>true</store-stats>
</input>
```


Any comments or questions are appreciated.


________________________________
Od: Andrej Leitner -X (anleitne - PANTHEON TECHNOLOGIES at Cisco) 
<[email protected]>
Odoslané: 16. mája 2016 15:46
Komu: Abhijit Kumbhare; [email protected]
Predmet: Re: [openflowplugin-dev] Some topics for the May 16 meeting

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

MiroslavMacko
Software Developer

Sídlo / Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
R&D centrum / Janka Kráľa 9 /  974 01 Banská Bystrica / Slovakia
/ [email protected]
reception: +421 2 206 65 114 / www.pantheon.sk

[logo]


TomášSlušný
Software Developer

Sídlo / Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
R&D centrum / Janka Kráľa 9 /  974 01 Banská Bystrica / Slovakia
+421 911 083 902 / [email protected]
reception: +421 2 206 65 114 / www.pantheon.sk

[logo]


_______________________________________________
openflowplugin-dev mailing list
[email protected]
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
  • [openflowplu... Abhijit Kumbhare
    • Re: [op... Andrej Leitner -X (anleitne - PANTHEON TECHNOLOGIES at Cisco)
      • Re:... Tomáš Slušný
        • ... Shuva Jyoti Kar
          • ... Tomáš Slušný

Reply via email to