Operating System: All
Platform: All

Made blocker as per: https://lists.opendaylight.org/pipermail/openflowplugin-dev/2016-May/005036.html

Make it a blocker for the release - but not for M3 (for Li migration default)

Sai, apart from LLDP flows , what are the other flows that are not seen in operational DS? since if i add a flow through restconf , i am able to see it in operDS

LLDP flows consistently not seen, also the default flows installed by controller (not the flows user installs using restconf) are not seen very often.

Hi Shuva any update on this.
Can we please make it as a blocker ?

Regarding other flows (not LLDP) you can refer to OPNFLWPLUG-736. But these two are independent bugs, which work in stable/ber.

with a lot many fixes that have gone in can you please test it out on the current plugin build(as of today) and let us know

Sai,

Please refer to this patch

https://git.opendaylight.org/gerrit/42851

(In reply to Shuva Jyoti Kar from comment #7)
> Sai,
>
> Please refer to this patch
>
> https://git.opendaylight.org/gerrit/42851

working on the fix, this is primarily happening since the flow-key is not unique.Still working on the actual/proper fix

the fix of appending the priority to the flowid to guarantee its uniqueness is not a good fix.
As we see, the flowid of both the flows are same, hence this issue occurs. The flowRegistryKey generation and comparison happens correctly, Is it possible to handle it at the application level itself?

Flows that are not seen in particular are LLDP and flow with action "dropall".

Flows on mininet:-
cookie=0x2b0000000000000b, duration=90.844s, table=0, n_packets=91, n_bytes=13134, priority=131 actions=CONTROLLER:65535
cookie=0x2b00000000000003, duration=5987.185s, table=0, n_packets=38, n_bytes=6573, priority=0 actions=drop

Shuva has a patch for this - https://git.opendaylight.org/gerrit/#/c/42851/. Needs to be reviewed by Anil & tested for performance by Shuva.

So, I was testing it, and when someone will add flow with for example ID 22, it is correctly added to config, operational and, deviceflowregistry and device.

Then, when someone add same flow, but just changes the id to for example 23, it will be replaced in config, replaced in deviceflowregistry, but removed from operational and device, because of FRM (becouse first, flow add is called, but FRM will see, that no flow with ID 22 is in config, so afterwards, it deletes that flow. But, because flow is unique by match, priority and table id, it removes that old/new flow with ID 23).

TL:DR
Adding 2 exactly same flows with different flow IDs is bad idea, because flow is not unique by flow id, and also, Shuvas patch what creates another alien and uses BiMap will not solve the problem, because it is not problem with DeviceFlowRegistry.

(In reply to Tomas Slusny from comment #12)
> So, I was testing it, and when someone will add flow with for example ID 22,
> it is correctly added to config, operational and, deviceflowregistry and
> device.
>
> Then, when someone add same flow, but just changes the id to for example 23,
> it will be replaced in config, replaced in deviceflowregistry, but removed
> from operational and device, because of FRM (becouse first, flow add is
> called, but FRM will see, that no flow with ID 22 is in config, so
> afterwards, it deletes that flow. But, because flow is unique by match,
> priority and table id, it removes that old/new flow with ID 23).
>
> TL:DR
> Adding 2 exactly same flows with different flow IDs is bad idea, because
> flow is not unique by flow id, and also, Shuvas patch what creates another
> alien and uses BiMap will not solve the problem, because it is not problem
> with DeviceFlowRegistry.

Tomas,
currently the problem is not with adding two flows with same

and different flowids, but with adding 2 different flows with the same flow id. This is because the flowregistry stores a unique(k,v) pair but fails to guarantee unique values.
so 2 flows with different match, priority,table-id and cookie} and same flow ids will be re-written in the oper-Ds (since flowKey contains the Flow id). Hence in the oper-Ds it appears as one.
With my patch, it will guarantee an uniqueness of(k,v) pairs. I have tested it with l2switch and i do see 2 distinct flws in the oper-Ds

https://git.opendaylight.org/gerrit/#/c/42851/

Sai,

Can you please test with the latest patchset of
https://git.opendaylight.org/gerrit/#/c/42851/
and let us know if that works for you?

Thanks Shuva.

I can see flows in operational.

pastebin link:- http://pastebin.com/tD75LBKA

One concern:- The drop all flow "action" is not seen in operational, any thoughts ?

Hi Sai,
afaik this is wanted behavior for now.

Since the flows are seen in the operational and the behaviour is similar to the earlier model of the plugin,marking the bug as reslved .