Operating System: All
Platform: All

Hideyuki how do you continue with this ?

Are you able use OFP Li design only with "is-statistics-rpc-enabled" or should we discuss more about it ?

Like Michal said we wont make "get-flow-statistics-from-flow-table" default in Boron release and I am not sure if it's good idea to make it default either in Beryllium release.

Just let us know. Meantime I lower the bug from major to enhancement.

Jozef

(In reply to Jozef Bacigal from comment #1)
> Hideyuki how do you continue with this ?
>
> Are you able use OFP Li design only with "is-statistics-rpc-enabled" or
> should we discuss more about it ?

Hi Jozef,

Thank you for checking the report!

VTN project needs the "get-flow-statistics-from-flow-table" RPC by default in Boron.

> Like Michal said we wont make "get-flow-statistics-from-flow-table" default
> in Boron release and I am not sure if it's good idea to make it default
> either in Beryllium release.
>

I don't think Michal said that.

He said "I think it makes more sense to cowardly give up on Li-design purity for Be release and enable it by default."
https://lists.opendaylight.org/pipermail/openflowplugin-dev/2016-January/004572.html

Here, I think "Be release" means "Beryllium release".

So he didn't say that OFP project won't make it default in Boron release, in my understanding.

And, I couldn't find any bad reasons to make it default.
Therefore, I would like the OFP project to make it default in Boron.

> Just let us know. Meantime I lower the bug from major to enhancement.
>
> Jozef

Hi all,
sorry for latency. There were definitely some misunderstandings.

We have rpc implementation for reading stats with notification side effect in Li-design ready and configurable via config subsystem. Present in Beryllium and master (current Boron). And disabled by default.

This backward compatibility API+implementation will be deprecated in Boron and replaced by notifications-free implementation probably with option to update DS/operational in order to support user-driven selective DS/operational synchronization. That's why these "old" rpcs can not be enabled by default in Boron.

But in Beryllium these "old" rpc can be enabled by default. Or at least I am not aware of any strong reason why not. There would be another routed rpc implementation available. This would not affect projects relying on DS/operational. And projects like VTN would get the compatibility support out of the box (in Beryllium) without adapting config xml files and providing customized karaf distro.

Hideyuki+JozefB: If we all agree on this then I can submit the change in config in Beryllium and Jozef - please file a bug for new rpcs with target milestone = Boron.

Hi Michal and Jozef,

Thank you for your comments.

VTN project doesn't use the Li-design in Beryllium. Therefore, we don't need the change in config in Beryllium.

In Boron, VTN project plans to use the Li-design, and needs a way to want latest information about flow entries in OpenFlow switches.
And, I think what you mentioned could be what we want.

"notifications-free implementation probably with option to update DS/operational in order to support user-driven selective DS/operational synchronization."

Jozef, could you give me the URL of the bug report in the bugzilla for the new RPC after you filed it?

VTN project wants the new RPC before the OFP project change the default plugin to the Li-design in the master branch.

https://bugs.opendaylight.org/show_bug.cgi?id=5692