-
Notifications
You must be signed in to change notification settings - Fork 469
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(network_routes): missing node ip -> error log #904
fix(network_routes): missing node ip -> error log #904
Conversation
thanks @aauren I think use of checked all the references for |
d966fdd
to
7092cf2
Compare
@murali-reddy Good catch! I added the instance of |
Sorry. My bad. I should have been more clear (references outside bgp_peers.go are all clean). There are 2 more such usages left in |
7092cf2
to
5a3308d
Compare
Before we used to raise an error when a node was missing an IP, but it turns out that this is not a required attribute of a node. And while it is rare that a node would be missing an IP address, a node doesn't require an IP address or a name or really much of anything in order to exist. This brings us to stronger conformance with the Kubernetes API and makes it so that kube-router logs errors rather than changing it's health status and potentially causing cascading failures across the fleet if a user adds a node like this.
5a3308d
to
d001b7a
Compare
@murali-reddy I fixed the remaining references in bgp_peers. Take another look when you have time. |
Thanks LGTM |
Before we used to raise an error when a node was missing an IP, but it turns out that this is not a required attribute of a node. And while it is rare that a node would be missing an IP address, a node doesn't require an IP address or a name or really much of anything in order to exist. This brings us to stronger conformance with the Kubernetes API and makes it so that kube-router logs errors rather than changing it's health status and potentially causing cascading failures across the fleet if a user adds a node like this.
Before we used to raise an error when a node was missing an IP, but it turns out that this is not a required attribute of a node. And while it is rare that a node would be missing an IP address, a node doesn't require an IP address or a name or really much of anything in order to exist. This brings us to stronger conformance with the Kubernetes API and makes it so that kube-router logs errors rather than changing it's health status and potentially causing cascading failures across the fleet if a user adds a node like this.
@murali-reddy This goes towards fixing another rare, but outstanding bug with kube-router for the 1.0.0 release.
Before we used to raise an error when a node was missing an IP, but it turns out that this is not a required attribute of a node. And while it is rare that a node would be missing an IP address, a node doesn't require an IP address or a name or really much of anything in order to
exist.
This brings us to stronger conformance with the Kubernetes API and makes it so that kube-router logs errors rather than changing it's health status and potentially causing cascading failures across the fleet if a user adds a node like this.
Properly fixes #846