You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
AFAICT, ValidateService doesn't check that a port is specified. What happens when no port is specified?
I also can't find anywhere where we check that 2 services don't ask for the same port.
Additionally, host ports may conflict with service ports. It would be useful to report such conflicts and to prevent the creation of services that conflict with host ports and vice versa.
Even after ip-per-service, some Services will have to use HostPorts (for External Load Balancer, for now). Much reduced, but that just makes a conflict even less common and harder to debug.
It boils down to: both Pods and Services can use HostPorts. We currently check Pods against other Pods for host-port conflicts, but we do not check Pods against Services, nor vice-versa, nor Services against Services.
We need some common way for both resource classes to check for conflicts and reserve HostPorts atomically.
Closing this, as it is no longer possible for services and pods to have port conflicts, unless a user does something manual (like specify a host IP for the "PublicIP" for a service)
Activity
brendandburns commentedon Sep 24, 2014
oops...
brendandburns commentedon Sep 25, 2014
This issue is largely deprecated. Will close with IP per service lands.
thockin commentedon Sep 30, 2014
IP-per-service does not eliminate this.
Even after ip-per-service, some Services will have to use HostPorts (for External Load Balancer, for now). Much reduced, but that just makes a conflict even less common and harder to debug.
It boils down to: both Pods and Services can use HostPorts. We currently check Pods against other Pods for host-port conflicts, but we do not check Pods against Services, nor vice-versa, nor Services against Services.
We need some common way for both resource classes to check for conflicts and reserve HostPorts atomically.
brendandburns commentedon Oct 21, 2014
Closing this as it is now obsolete with service v2.
craigmcl commentedon Oct 28, 2014
This is to be addressed in v0.5.
brendandburns commentedon Dec 16, 2014
Closing this, as it is no longer possible for services and pods to have port conflicts, unless a user does something manual (like specify a host IP for the "PublicIP" for a service)
Merge pull request kubernetes#974 from yifan-gu/godep_glog
Merge pull request kubernetes#974 from openshift-cherrypick-robot/cheâĶ