https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/OPNFLWPLUG-702 OpenFlowPlugin <p>Staring in Beryllium SR2, we get ~1440 lines of JSON for table features for <b>every</b> table in every switch, which for OVS results in ~368,640 lines and 18 MB per switch. While I applaud us gathering all the information we can, we need to find a way to make this less painful.</p> <p>See the attached JSON for querying:<br/> restconf/operational/opendaylight-inventory:nodes/node/openflow:212</p> <p>Operating System: All<br/> Platform: All</p> OPNFLWPLUG-702

Excessive data in inventory in Beryllium SR2

Bug Resolved Won't Do Unassigned Colin Dixon Tue, 24 May 2016 15:03:36 +0000 Mon, 27 Sep 2021 09:01:49 +0000 Tue, 6 Jun 2017 07:21:03 +0000 General 0 5 <p>Attachment odl-inv.json.zip has been added with description: json for a single OVS switch in the inventory generating 18MB of data</p> <p>Hi Colin - right, those huge ugly data are table-features.<br/> In my opinion these shall not be stored in DS/operational. This would decrease size of stored data. </p> <p>But app working with table-features would have to read it every time via rpc. Which is probably a good trade off, but we need to discuss that with NIC and DIDM the impact.</p> <p>That would be one approach and it would certainly be better than the current situation. It's unfortunate that we can't have the data there but not read it by default.</p> <p>I think recently we added a nob to the enable/disable the table features in lithium plugin and we are working on implementing the same in He plugin as well. But this is short term solution, but i agree we should go with rpc based solution. RPCs are accessible to both controller internal application as well as external application, so both type of application can fetch it. The issue with rpc approach is, if number of application increases and plugin start getting more table feature request, that will put load on the openflowjava, for processing the same information. Alternate solution is to dump these table features under different tree node "/node/openflow:xxx/table-features/1/", so if application need to read it, they should go to other path, rather than the "node/table/flow" path where frequently used information is stored.</p> <p>Also we can create new root container to hold large table features (outside inventory). <br/> There will be similar structure so that current functionality can be supported (listening to changes in DS/operational and changing tables via DS/config).</p> <p>That will scatter the node related information across the model and that probably will create more problem for the applications. What about another augmentation on the node &#8211; "flow-capable-node-table-features"?</p> <p>That would open optimization door for java-api access (reading, listening).<br/> But via restconf - augmentations are invisible - so exploration of whole device in inventory will still contain table-features.</p> <p>Do we know if the depth= parameter of RESTCONF still works? That might be a work around.</p> <p>Also, only storing non-empty tables would help a lot, but I understand it's still information.</p> <p>Was this a change in functionality between Beryllium release and SR2? My guess is most people would see generating an extra ~370,000 lines of data as a significant change in behavior to be introduced in an SR.</p> <p>I see this patch:<br/> <a href="https://git.opendaylight.org/gerrit/#/c/36506/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/36506/</a></p> <p>which seems to offer a way to disable this, but was just after SR2.</p> <p>Does that work? Would it be a partial fix?</p> <p>Table features functionality was part of the beryllium release from the first release. We do have patches up for review that provides option to disable/enable the functionality.</p> <p><a href="https://git.opendaylight.org/gerrit/#/c/39150/6" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/39150/6</a><br/> <a href="https://git.opendaylight.org/gerrit/#/c/39005/7" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/39005/7</a></p> <p>For Helium plugin, table features are enabled by default, because DIDM/NIC project needs table features. We can't disable it till they move to alternate way to fetch the table features (rpc) or enable it specifically for their own project.</p> <p>The real reason for suddenly having table features is that ovs started to announce them since version 2.4. We had table features with cpqd during Li already.</p> <p>Now we have at least 2 projects (NIC, DIDM) which rely on reading table features from DS/operational. So disabling table features is not really a solution.</p> <p>I guess we should inspect first if use-cases of those projects conflict and need to get notified upon table features changed. If not then we can assume:</p> <ul class="alternate" type="square"> <li>table features are rather static (changing them automatically removes all flows so it makes sense to change these only once at the beginning or as part of preconfiguration / reconciliation)</li> <li>table features can be evicted from DS/operational and will be accessible on demand via rpc without inflating DS/operational</li> <li>if there is usecase where an app needs to track table features changes then we can use md-sal notification</li> </ul> <p>He design only fetch is once when switch connects to the controller, because as of now i believe table feature config is not supported. I think this is not just a problem with plugin performance, but for applications as well. It generates around 3.5 MB of data per switch, so any external application that's listening for the change notification through web socket, will get this huge amount of data and processing 3.5MB of data per switch will pretty much kill the performance of the external application. I personally feel that we should recommend applications to use rpc to fetch the table features.</p> <p>It sounds like, in the short-run, the only way to fix this would be to move the table features information somewhere else: either an RPC or a separate model. </p> <p>In the long run, it seems like we'd like a more generic way for people get just want they want from RESTCONF. Maybe the answer is iterative depth-limited calls? That is you first get the list of switches, then you can just fetch what you want about the switches?</p> <p>Closing this bug because there will be no more releases in Beryllium.</p> Development External issue ID 5954 External issue URL Rank 0|i032s7: