-
Notifications
You must be signed in to change notification settings - Fork 194
agent: smarter readiness check #485
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
agent: smarter readiness check #485
Conversation
Hi @ipochi. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/ok-to-test |
135bc49
to
a61723a
Compare
/test pull-apiserver-network-proxy-test |
This looks pretty close. @mihivagyok can you verify that this meets the requirements of #491? |
a61723a
to
6fd7d33
Compare
6fd7d33
to
1b6c4be
Compare
readinessHandler := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { | ||
fmt.Fprintf(w, "ok") | ||
var failedChecks []string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This section is very close to fully generic. It would be nice to organize it somewhere different than cmd/agent to keep that minimal. It would also be good to add some unit test coverage (for example: exercise the verbose codepath).
I'm ok with deferring these suggestions, to unblock making the feature available.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO, I'd like to get this merged as is.
The addition of unit tests, while useful would require more thoughts and time and the result would be a very trivial check and not worth the effort and time.
This commit introduces a smarter way for the readiness check. Currently as soon as the agent is up, it signals itself as ready regardless of whether its actually connected to the server or not. This commit introduces a readiness check in the Agent which reports true if its connected to atleast one proxy server. Signed-off-by: Imran Pochi <imranpochi@microsoft.com>
5c5006d
to
f5170c1
Compare
Did you see the feedback: But can you make small adjustments to make it more obvious to future readers? For example, only introduce readiness.go (not healthz.go), and avoid code naming like "HealthZ" (which some readers may think implies liveness health). I'm actually OK with merging as-is, and we can always address the above separately. Adding a hold just so that @cheftako can also look. /hold |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ipochi, jkh52 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Signed-off-by: Imran Pochi <imranpochi@microsoft.com>
f5170c1
to
581b1f8
Compare
/lgtm Feel free to remove the hold in a day or two, if no other reviewers have feedback. |
@jkh52 How does one remove hold ? |
I believe it is "/remove-hold" |
/remove-hold |
This commit introduces a smarter way for the readiness check.
Currently as soon as the agent is up, it signals itself as ready regardless of whether its actually connected to the server or not.
This commit introduces a callback function and a connected field in ClientSet struct to update the status of the agent -> proxy-server connection at regular intervals.
Concern: This makes the assumption that the client is connected to at least one proxy server and therefore the status is ready.
I've thought about updating the readiness of the agent only when all proxy-servers are connected but wasn't sure about the implications from the kubernetes side,
since this being a readiness check , kubernetes might treat the pod as not ready and not send any traffic.EDIT: Since the agent pods are not behind a Kubernetes service, the readiness of the pod doesn't really matter.
Please share your reviews,concerns to the approach I've taken.
/cc: @jveski @cheftako @jkh52 @tallclair