Yes, with <store-stats>false</store-stats> you will get the statistics as
output, but it will not update the operational datastore.
By default (when omitted) store-stats is false.
And yes again, when we send get-flow-statistics without specifying any
parameters, we will get all flows for all tables.
get-flow-statistics currently have input parameters as entire flow, and all of
them are optional and have default values. So, for getting all flows from table
2, you can just do:
/restconf/operations/opendaylight-direct-statistics:get-flow-statistics
```
<input xmlns="urn:opendaylight:direct:statistics">
<node
xmlns:inv="urn:opendaylight:inventory">/inv:nodes/inv:node[inv:id="openflow:1"]</node>
<table_id>2</table_id>
</input>
```
And no, input will be that what I sent earlier, but I think I forgot to add
there URL for REST call, so URL in that example will be
/restconf/operations/opendaylight-direct-statistics:get-group-statistics
if I understand it correctly.
________________________________
Od: Shuva Jyoti Kar <[email protected]>
Odoslané: 16. mája 2016 16:56
Komu: Tomáš Slušný; [email protected]
Kópia: [email protected]
Predmet: RE: [openflowplugin-dev] Some topics for the May 16 meeting
So with <store-stats> false</store-stats> we “can” get stats but not update the
Oper DS , is my understanding correct ?
Also if we send get-flow-statistics without specifying flow-id will it give the
flow stats across all tables ?
--If that is the case can we have one get-flow-table-stats, something that can
retrieve all flows for a given table ?
--If not what will it give ?
And finally in the example given will the input be as :
<input xmlns="urn:opendaylight:direct:statistics:get-group-statistics ">
Thanks
Shuva
From: [email protected]
[mailto:[email protected]] On Behalf Of Tomáš
Slušný
Sent: Monday, May 16, 2016 8:07 PM
To: [email protected]
Cc: [email protected]
Subject: Re: [openflowplugin-dev] Some topics for the May 16 meeting
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]<mailto:[email protected]>>
Odoslané: 16. mája 2016 15:46
Komu: Abhijit Kumbhare;
[email protected]<mailto:[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]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
on behalf of Abhijit Kumbhare
<[email protected]<mailto:[email protected]>>
Sent: Wednesday, May 11, 2016 6:09 PM
To:
[email protected]<mailto:[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]<mailto:[email protected]>
reception: +421 2 206 65 114 / www.pantheon.sk<http://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]<mailto:[email protected]>
reception: +421 2 206 65 114 / www.pantheon.sk<http://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
