Replaced the webhook readiness init container logic to use curl

[chrislusf]

Fix #159

Replaced the webhook readiness init container logic to use curl with modern TLS support, avoiding the BusyBox wget handshake failure during certificate patch jobs.

Summary by CodeRabbit

Release Notes

• Documentation

  • Added documentation for webhook initialization container image configuration

• Chores

  • Enhanced webhook readiness verification in Helm deployment
  • Updated webhook initialization container image

[coderabbitai]

Caution

Review failed

The pull request is closed.

Note

Other AI code review bot(s) detected

CodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review.

Walkthrough

The changes replace the webhook readiness check mechanism from wget-based health probing to curl-based health probing. This involves updating the Helm template to use curl instead of wget, changing the init container image from busybox to a dedicated curl image, and documenting the new configuration option.

Changes

Cohort / File(s)	Summary
Webhook readiness check refactor deploy/helm/templates/_helpers.tpl	Replaces wget --spider --timeout with curl -sk --fail --head --max-time 5 for webhook TLS readiness verification
Init container image update deploy/helm/values.yaml	Changes webhook initContainer image from busybox:1.37 to curlimages/curl:8.8.0 to support TLS handshake compatibility
Configuration documentation deploy/helm/README.md	Documents new webhook.initContainer.image configuration value in the Values table

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Verify curl command syntax and flags produce equivalent behavior to the original wget command
• Confirm the curl image version is appropriate and available in target registries
• Ensure the TLS compatibility improvement addresses the root cause from issue #159

Poem

🐰 A busybox's wget was feeling quite blue,
TLS handshakes it could not push through!
So curl came to rescue with grace and with flair,
Now webhooks are checking with nary a care! ✨

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix-tls

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 9c93b21 and 09b1801.

📒 Files selected for processing (3)

• deploy/helm/README.md (1 hunks)
• deploy/helm/templates/_helpers.tpl (1 hunks)
• deploy/helm/values.yaml (1 hunks)

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[gemini-code-assist]

Summary of Changes

Hello @chrislusf, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request enhances the stability of the webhook component by replacing the wget-based readiness check with a more robust curl-based approach. This modification resolves a known problem with wget's TLS handling during certificate patching, ensuring smoother operation and better compatibility with modern TLS configurations. Additionally, it provides greater flexibility by making the init container image configurable via Helm.

Highlights

• Webhook Readiness Check Improvement: The logic for the webhook readiness init container has been updated to use curl instead of wget.
• TLS Handshake Failure Resolution: This change specifically addresses issues where BusyBox wget would fail during TLS handshakes when patching certificates, improving the reliability of the webhook.
• Configurable Init Container Image: A new Helm value, webhook.initContainer.image, has been introduced, allowing users to specify the image used by the webhook readiness init container. The default has been updated to curlimages/curl:8.8.0.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request replaces the wget command with curl in the webhook readiness init container to resolve TLS handshake failures. The changes are well-contained, updating the Helm template, default values, and documentation. My review includes a suggestion to make the new curl command more robust and efficient.

[gemini-code-assist]

The curl command uses --connect-timeout, which only limits the time for establishing a connection. If the connection is made but the server is slow to respond, the command could still hang. It's better to use --max-time to limit the total duration of the operation, which is more equivalent to wget's --timeout behavior.

Additionally, since we are only checking for service readiness and not interested in the content, using the --head flag to only fetch HTTP headers would be more efficient, similar to wget's --spider option.

I suggest updating the command to use --max-time and --head for better robustness and efficiency.

  command: ['sh', '-c', 'set -e; until curl -sk --fail --head --max-time 5 https://{{ include "seaweedfs-operator.fullname" . }}-webhook.{{ .Release.Namespace }}.svc:443{{ .webhookPath }} >/dev/null; do echo waiting for webhook; sleep 1; done;']