[OPNFLWPLUG-519] [GROUP-CHAINING]Deleting a child Indirect-Group from a parent All-group does not delete the parent from the config DS. Created: 29/Jul/15  Updated: 27/Sep/21  Resolved: 02/Nov/15

Status: Resolved
Project: OpenFlowPlugin
Component/s: General
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Pompina Singh Assignee: Muthukumaran Kothandaraman
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: Other

Attachments: File group_ChainingUnsup.pcap    
External issue ID: 4064

 Description   

The configuration that we are trying out is an All group pointing to multiple Indirect groups.

(3)-->

{1,2}

We have tried deleting the "indirect" group type with group id = 2 which is a child of group type "all" with group id = 3.
Group id 3 also has "indirect" group type with group id - 1. The config DataStore shows group-1 and group-3.

The parent All group is should get deleted when the child indirect group is deleted .

This can be a problem during reconciliation. If the switch goes down or crashes and the controller adds a different group with group-id 2, when the switch restarts it will have a wrong set of groups.

Test steps executed :

1- Connect cpqd switch to controller.
2- Push groups using REST ( POSTMAN app ). Group-1=> type group-indirect, Group-2=> type group-indirect,Group-3=> type group-all.
3- Now delete Group 2 .
4. Group gets deleted from switch but not from config datastore.

Now if we

1.Stop the switch
2.Add a new group with same group-id but different action
3.Start the switch
4.The switch has the wrong set of groups as the parent group still points to the (old)two child ones.

Hence its a major problem during group-reconciliation

 Comments   
Comment by Pompina Singh [ 29/Jul/15 ]

Attachment group_ChainingUnsup.pcap has been added with description: Wireshark capture showing the problem

Comment by Pompina Singh [ 29/Jul/15 ]

The capture is with cpqd where the deletion fails as it cannot delete the parent.Still it is removed from config DS

Comment by Abhijit Kumbhare [ 25/Sep/15 ]

Muthu,

Is this fixed as part of reconciliation?

Thanks,
Abhijit

Comment by Abhijit Kumbhare [ 25/Sep/15 ]

Muthu,

Is this fixed as part of reconciliation?

Thanks,
Abhijit(In reply to Abhijit Kumbhare from comment #3)
> Muthu,
>
> Is this fixed as part of reconciliation?
>
> Thanks,
> Abhijit

Actually Muthu - can you confirm if it is really a bug and if we really should fix this?

Comment by Abhijit Kumbhare [ 30/Oct/15 ]

(In reply to Abhijit Kumbhare from comment #4)

>
> Actually Muthu - can you confirm if it is really a bug and if we really
> should fix this?

Any thoughts Muthu?

Comment by Muthukumaran Kothandaraman [ 30/Oct/15 ]

HI Abhijit,

This type of group-relationships are rare - agreed. So, we have to see this from 2 perspectives
1. Spec compliance - checked 1.3.1 spec and it does not explicitly mention about this specifically
2. Even if we fix this, would it be verifiable using OVS (even with OVS 2.5)

I will have a quick check on these aspects and update the bug.

Comment by Luis Gomez [ 31/Oct/15 ]

I do not really get the point here, in existing plugin implementation using config ds the user has to be careful of not doing stuff that can confuse the switch like deleting a group that is defined in another group or a flow. If we were to do an enhancement here would be to not allow to delete a group that is part of a flow or a group but these kind of checkings (many i can think of) can go against plugin performance as we discussed in the past.

Comment by Muthukumaran Kothandaraman [ 31/Oct/15 ]

Hi Luis,

Yes. Performance is also one of reasons why the decision to proceed further on this bug is blocked. If the spec does not say anything in this context, we can give the benefit of doubt in favor of performance and can close this bug without fix.

Comment by Muthukumaran Kothandaraman [ 02/Nov/15 ]

This must be taken care of by applications

Generated at Wed Feb 07 20:32:42 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.