Operating System: Linux
Platform: All

Attachment Group-outPort-issue.pcap has been added with description: Capture showing the group mod fails

Hi Hari,
why does the port come up later? It there any proposed solution?

(In reply to michal rehak from comment #1)
> Hi Hari,
> why does the port come up later? It there any proposed solution?

Hi Michal,

CCd Shuva Jyoti Kar

Ask seems to be in a pre-provisioning scenario where the group config is applied and port is brought up later.

Shuva - please confirm if my assumption is correct.

If we need at the least, the configuration in the config-data-store should be enhanced for pre-provisioning scenarios and notified once the configuration is ready to be applied.

Thanks,
Hari

Yes Hari. What you have mentioned is the exact case - pre-provisioning and/or switch reboot. Ports can come up arbitrarily due to admin-action or due to other differences. So, below mentioned groups can fail.

Yes Hari absolutely. Switch reboot/ pre-provisioning

ok, having pre-provisioning aside, shouldnt the application make sure the reboot and ports are up before configuring the groups?

Otherwise we need a retrying mechanism for this kind of transaction.

Michal, please shed your views.

Thanks,
Hari

The current reconcilitation model is application agnostic -whenever the switch connects it just sends the groups/meters/flows. Either the reconciliation model has to enhanced to make it application-aware or there has to be a retry-mechanism for failed transactions during reconciliation – could be based on certain triggers or even retry the task after a timeout of t interval for n times(max). The latter will however entail increased usage of the control plane b/w.

Hi all,
we have also OPNFLWPLUG-522 being caused by ignored precondition for a group too.

Lets consider timeout and retry based solutions as last emergency and unstable option and focus on defining those preconditions.

We have:
1. group depending on other group
2. group depending on port

For 1. we can compute dependency tree and push groups in special order with a few barriers in between.
For 2. we have to wait for port somehow. My first idea is to finish basic reconciliation and setup a one-shot selfdestructive dataChangeEvent listener (pointing to particular node-connector) covering reconciliation of depending groups.

And I believe that 1. and 2. might need to cooperate. And also the final group push plan with event-driven and dependency-driven order can be fully prepared during base reconciliation.

We might want to discard those one-shot dataChangeEvent listeners after some timeout but that is just an optimization.

Does anyone know about some more preconditions for groups?

Thanks Michal.

Defining pre-conditions and solving will preclude retry/timeout approaches inherently.

Preconditions:
1. group depending on other group
2. group depending on port

More I can think off:
3. Flow depending on group, meter, port?

Moreover, group referring groups are not supported till OVS < 2.5. I see OVS 2.3.2 is the latest official release.

Please check:
http://comments.gmane.org/gmane.linux.network.openvswitch.general/9336

<----Snipped from openvswitch discussion---->
Ben Pfaff | 23 Jun 17:35 2015
Re: [ovs-discuss] Groups within groups

On Tue, Jun 23, 2015 at 03:48:38PM +0530, Kavitha_Ramalingham <at> Dell.com wrote:
> We always see that the traffic is not sent out of the ports described
> in the flows, when a flow uses a Group ID that in turn uses another
> group ID in the "actions" qualifier. This appears to be a bug. Can you
> pl. look into it.

OpenFlow doesn't require support of group chaining. OVS 2.4 and earlier
don't support group chaining, but OVS 2.5 will.

Hi Hari,

Yes flows depending on groups can also be considered as a precondition-- but since the current reconciliation model provisions groups ahead of flows and meters i did not see any issue there.

However in case you are looking for a switch that supports group-chaining you can use cpqd for it.

(In reply to Shuva Jyoti Kar from comment #9)
> Hi Hari,
>
> Yes flows depending on groups can also be considered as a precondition-- but
> since the current reconciliation model provisions groups ahead of flows and
> meters i did not see any issue there.
>
> However in case you are looking for a switch that supports group-chaining
> you can use cpqd for it.

cpqd supports ovs2.5? I see the version is 2.3 in cpqd page. Could you share the cpqd url with ovs 2.5?

Hi Hari,

I do not understand your question , but cpqd does support group-chaining and group forwarding to ports , hence the suggestion.

(In reply to Shuva Jyoti Kar from comment #11)
> Hi Hari,
>
> I do not understand your question , but cpqd does support group-chaining and
> group forwarding to ports , hence the suggestion.

Will this help me?
https://github.com/CPqD/ofsoftswitch13

For group chaining yes

Shuva is already working in the reconciliation and working on review comments. Requested him to take this defect and 4069.Setting the owner to default.

Shuva - any thoughts/updates?

Currently working on it

Testing the fix ,
Since the fix involves a config-subsystem parameter, it actually depends on the fix for BUG:4062, that Muthu has raised for a review . Will be waiting till that review is merged , since it needs to be retested post it

Review link :https://git.opendaylight.org/gerrit/#/c/29267

Shuva,

Can you fix the path conflicts so that this can be merged? Also can you cherry pick it to stable/beryllium? Anil has already +2'ed the change.

Thanks,
Abhijit

Shuva,

Can you please rebase it so that it can be merged?

Abhijit

Abhijit,

Sure will do that at the earliest, some urgent tasks to be brought to closure before i can settle on this. The rebasing is not helping- i will have to re-raise a separate review.

thanks

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