Closed OnlyPiglet closed 8 months ago
here is the related code,we may need to judge is this listener is user managed like delete action
pkg/controller/service/clbv1/listeners.go
for _, rlis := range remote.Listeners {
found := false
for _, llis := range local.Listeners {
if rlis.ListenerPort == llis.ListenerPort && rlis.Protocol == llis.Protocol {
found = true
// listener and protocol match, do update here we may need to judge is this listener is user managed like delete action ??
updateActions = append(updateActions,
UpdateAction{
lbId: remote.LoadBalancerAttribute.LoadBalancerId,
local: llis,
remote: rlis,
})
}
}
// Do not delete any listener that no longer managed by my service
// for safety. Only conflict case is taking care.
if !found {
if !isPortManagedByMyService(local, rlis) {
reqCtx.Log.Info(fmt.Sprintf("update listener: port [%d] namekey [%s] is managed by user, skip reconcile", rlis.ListenerPort, rlis.NamedKey))
continue
}
deleteActions = append(deleteActions, DeleteAction{
lbId: remote.LoadBalancerAttribute.LoadBalancerId,
listener: rlis,
})
}
}
If the slb is created by a service with loadbalancer type, the SLB configuration will be synchronized based on the service configuration. And if you reuse a slb and set force-override
to true
, the slb also will be updated based on the service.
If you reuse a slb and set force-override
to false
, ccm will not manage the listener.
If the slb is created by a service with loadbalancer type, the SLB configuration will be synchronized based on the service configuration. And if you reuse a slb and set
force-override
totrue
, the slb also will be updated based on the service. If you reuse a slb and setforce-override
tofalse
, ccm will not manage the listener.
I mean is if the listener is managed manually before, ccm should not update it even force-override is true,because the listener is managed by manual before . and service port may be misconfiguration.
If the slb is created by a service with loadbalancer type, the SLB configuration will be synchronized based on the service configuration. And if you reuse a slb and set
force-override
totrue
, the slb also will be updated based on the service. If you reuse a slb and setforce-override
tofalse
, ccm will not manage the listener.I mean is if the listener is managed manually before, ccm should not update it even force-override is true,because the listener is managed by manual before . and service port may be misconfiguration.
because is I set force-override false, normal listener will not sync too
I thinks this is better
for _, rlis := range remote.Listeners {
found := false
for _, llis := range local.Listeners {
if rlis.ListenerPort == llis.ListenerPort && rlis.Protocol == llis.Protocol {
found = true
// listener and protocol match, don't update any listener that no longer managed by my service
if !isPortManagedByMyService(local, rlis) {
reqCtx.Log.Info(fmt.Sprintf("update listener: port [%d] namekey [%s] is managed by user, skip reconcile", rlis.ListenerPort, rlis.NamedKey))
continue
}
updateActions = append(updateActions,
UpdateAction{
lbId: remote.LoadBalancerAttribute.LoadBalancerId,
local: llis,
remote: rlis,
})
}
}
// Do not delete any listener that no longer managed by my service
// for safety. Only conflict case is taking care.
if !found {
if !isPortManagedByMyService(local, rlis) {
reqCtx.Log.Info(fmt.Sprintf("delete listener: port [%d] namekey [%s] is managed by user, skip reconcile", rlis.ListenerPort, rlis.NamedKey))
continue
}
deleteActions = append(deleteActions, DeleteAction{
lbId: remote.LoadBalancerAttribute.LoadBalancerId,
listener: rlis,
})
}
}
@gujingit if there is any update,I will happy to commit a pr for this
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
What happened:
if I add a tcp protocol 80 listener on slb , and then I add a load balancer service with protocol tcp and port 80, this will update original , I think it's better not to update listener which is user manage is better. right?
What you expected to happen:
not to update listener which is user manage is better
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
Environment: