@@ -10,25 +10,25 @@ import (
1010)
1111
1212/*
13- dirtyCacheInterface will maintain the dirty cache.
14- It may maintain membersToAdd and membersToDelete.
15- Members are either IPs, CIDRs, IP-Port pairs, or prefixed set names if the parent is a list.
16-
17- Assumptions:
18- - if the set becomes dirty via update or destroy, then the set WAS in the kernel before
19- - if the set becomes dirty via create, then the set was NOT in the kernel before
20-
21- Usage:
22- - create, addMember, deleteMember, and destroy are idempotent
23- - create should not be called if the set becomes dirty via add/delete or the set is removed from the deleteCache via add/update
24- - deleteMember should not be called if the set is in the deleteCache
25- - deleteMember is safe to call on members in the kernel and members added via addMember
26- - deleteMember is also safe to call on members not in the kernel if the set isn't in the kernel yet (became dirty via create)
27-
28- Examples of Expected Behavior:
29- - if a set is created and then destroyed, that set will not be in the dirty cache anymore
30- - if a set is updated and then destroyed, that set will be in the delete cache
31- - if the only operations on a set are adding and removing the same member, the set may still be in the dirty cache, but the member will be untracked
13+ dirtyCacheInterface will maintain the dirty cache.
14+ It may maintain membersToAdd and membersToDelete.
15+ Members are either IPs, CIDRs, IP-Port pairs, or prefixed set names if the parent is a list.
16+
17+ Assumptions:
18+ - if the set becomes dirty via update or destroy, then the set WAS in the kernel before
19+ - if the set becomes dirty via create, then the set was NOT in the kernel before
20+
21+ Usage:
22+ - create, addMember, deleteMember, and destroy are idempotent
23+ - create should not be called if the set becomes dirty via add/delete or the set is removed from the deleteCache via add/update
24+ - deleteMember should not be called if the set is in the deleteCache
25+ - deleteMember is safe to call on members in the kernel and members added via addMember
26+ - deleteMember is also safe to call on members not in the kernel if the set isn't in the kernel yet (became dirty via create)
27+
28+ Examples of Expected Behavior:
29+ - if a set is created and then destroyed, that set will not be in the dirty cache anymore
30+ - if a set is updated and then destroyed, that set will be in the delete cache
31+ - if the only operations on a set are adding and removing the same member, the set may still be in the dirty cache, but the member will be untracked
3232*/
3333type dirtyCacheInterface interface {
3434 // reset empties dirty cache
@@ -96,7 +96,7 @@ func (dc *dirtyCache) create(set *IPSet) {
9696 if _ , ok := dc .toUpdateCache [set .Name ]; ok {
9797 msg := fmt .Sprintf ("create should not be called for set %s since it's in the toUpdateCache" , set .Name )
9898 klog .Warning (msg )
99- metrics .SendErrorLogAndMetric (util .IpsmID , msg )
99+ metrics .SendErrorLogAndMetric (util .IpsmID , "%s" , msg )
100100 return
101101 }
102102
@@ -136,7 +136,7 @@ func (dc *dirtyCache) deleteMember(set *IPSet, member string) {
136136 if dc .isSetToDelete (set .Name ) {
137137 msg := fmt .Sprintf ("attempting to delete member %s for set %s in the toDestroyCache" , member , set .Name )
138138 klog .Warning (msg )
139- metrics .SendErrorLogAndMetric (util .IpsmID , msg )
139+ metrics .SendErrorLogAndMetric (util .IpsmID , "%s" , msg )
140140 return
141141 }
142142 if diff , ok := dc .toCreateCache [set .Name ]; ok {
0 commit comments