Skip to content

chore: remove reference to min-ready#2419

Merged
jackwotherspoon merged 4 commits intoGoogleCloudPlatform:mainfrom
dmarkwat:readiness
Apr 4, 2025
Merged

chore: remove reference to min-ready#2419
jackwotherspoon merged 4 commits intoGoogleCloudPlatform:mainfrom
dmarkwat:readiness

Conversation

@dmarkwat
Copy link
Copy Markdown
Contributor

@dmarkwat dmarkwat commented Apr 2, 2025

Addresses a gap in the documented behavior for /readiness checks which states:

Optionally supports a min-ready query param (e.g., /readiness?min-ready=3) where the Proxy will return a 200 status if the Proxy can connect successfully to at least min-ready number of instances. If min-ready exceeds the number of registered instances, returns a 400.

This is a proposal to close that gap. One deficiency is clear, though, which is that it opens connections as part of the readiness endpoint which may slow its response time in certain connection conditions. Curious if there's suggestions to address this, but ultimately the documented feature isn't implemented and needs to be to properly support HA cloudsql configurations.

@dmarkwat dmarkwat requested a review from a team as a code owner April 2, 2025 21:28
@enocom
Copy link
Copy Markdown
Member

enocom commented Apr 2, 2025

We actually removed this deliberately and didn't update the docs 🤦

See #2207.

So this is could be a documentation PR.

@dmarkwat
Copy link
Copy Markdown
Contributor Author

dmarkwat commented Apr 3, 2025

Fair. Unfortunate, but fair.

Perhaps you can lend some insight then into how best to handle this particular situation:

We are configuring HA databases and the idea is that when one of them is down, the other should still be accessible -- bc HA, of course. Will readiness still report as operable if one of the replicas configured is down? What will happen in the event all are down? Will readiness still report OK?

The doc is mum on this which is why we pursued this, as we'd observed behavior that suggested when one was down readiness was no longer OK and the pods were pulled from their k8s Services. But looking at the code once more, this may have been isolated to cloud sql v1 as I'm not seeing how that would manifest here unless stopped or started were somehow tripping the failure.

@enocom
Copy link
Copy Markdown
Member

enocom commented Apr 3, 2025

Would you mind opening an issue for this so we can help other people discover it?

Short answer: configure readiness probes through your app rather than the Proxy. These probes might then traverse the proxy in reaching to the backing instance. This way you can configure whatever behavior makes sense for the problem you're trying to solve.

@dmarkwat
Copy link
Copy Markdown
Contributor Author

dmarkwat commented Apr 3, 2025

Opened #2420

I'll revert my changes and update the doc in this PR instead.

@enocom
Copy link
Copy Markdown
Member

enocom commented Apr 3, 2025

Thank you!

@dmarkwat
Copy link
Copy Markdown
Contributor Author

dmarkwat commented Apr 3, 2025

🫡 my pleasure. Appreciate the quick responses! Done.

@dmarkwat dmarkwat changed the title fix: adds min-ready support for readiness check chore: adds min-ready support for readiness check Apr 3, 2025
@jackwotherspoon jackwotherspoon changed the title chore: adds min-ready support for readiness check chore: remove reference to min-ready Apr 4, 2025
Copy link
Copy Markdown
Collaborator

@jackwotherspoon jackwotherspoon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍 Thanks @dmarkwat 👏

@jackwotherspoon jackwotherspoon merged commit b139a27 into GoogleCloudPlatform:main Apr 4, 2025
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants