docs(secrets): fix the unrunnable SMTP seal recipe blocking #500 - #501
Merged
Conversation
) The go-live recipe for sealing SMTP_USER/SMTP_PASS into fuzefront-secrets was unrunnable, so the two keys were never sealed and the prod email-service rollout wedged in CreateContainerConfigError (issue #500). Fixes: - seal-secret.sh flags: --from-file/--into do not exist -> --in/--manifest, matching the working Twilio recipe in the same doc. - Add the REQUIRED --scope fuzefront/fuzefront-secrets: the script defaults to name=billing-secrets, so without it the value seals into the wrong secret and the controller can never decrypt it into fuzefront-secrets. - Provider: Zoho -> ZeptoMail (values-prod already sets host smtp.zeptomail.com; the doc prose was stale). - Cert URL: sealed-secrets.fuzeinfra.fuzefront.com no longer resolves -> sealed-secrets.prod.fuzefront.com (canonical). - Note that the host is already set, so sealing the two keys is the only remaining owner action; the new RS self-heals / restart to force it. No chart/template change: the Deployment + prod values are already wired correctly. The actual sealing needs the real ZeptoMail credentials and is owner-only (never committed/pasted). Co-Authored-By: Claude claude-opus-4-8 <noreply@anthropic.com> Claude-Session-Id: 36eb28ad-656a-4cf3-849e-63562ac341f9
Contributor
Automated code review (gate-code-review)Credit balance is too low Report-only — this check never blocks merge. |
Comment-only. Completes the provider-naming cleanup started in the SEAL_PROD_SECRETS.md fix — the chart still referenced Zoho/smtp.zoho.com in three places while prod actually relays through ZeptoMail: - values.yaml: example host smtp.zoho.com → smtp.zeptomail.com - email-service.yaml: "relay like Zoho" → "relay like ZeptoMail" - values-prod.yaml: the host comment claimed "set this ONLY once sealed" but the host is already set; reworded to state the keys must be sealed (setting the host before sealing them is what wedged the #500 rollout). No rendered-manifest change (comments only). Also re-triggers the push-only Stranded-branch detector, which now early-exits green because PR #501 already exists (its prior red was a push-before-PR race). Co-Authored-By: Claude claude-opus-4-8 <noreply@anthropic.com> Claude-Session-Id: 36eb28ad-656a-4cf3-849e-63562ac341f9
Contributor
Automated code review (gate-code-review)Credit balance is too low Report-only — this check never blocks merge. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What & why
Issue #500: the prod
fuzefront-email-servicerollout is wedged inCreateContainerConfigErrorbecauseSMTP_USER/SMTP_PASSwere never sealed into thefuzefront-secretsSealedSecret. Root cause of why they were never sealed: the owner-only go-live recipe indeploy/contabo/SEAL_PROD_SECRETS.mdwas unrunnable.The SMTP section used
--from-fileand--into— neither flag exists indeploy/scripts/seal-secret.sh(it accepts--in/--scope/--manifest). Worse, it omitted--scope fuzefront/fuzefront-secrets, and the script defaults toname=billing-secrets— so even if the flags were valid, the value would have sealed into the wrong secret and never decrypted intofuzefront-secrets. The Twilio recipe immediately below it in the same doc is correct; this aligns SMTP to it.Changes (doc only — no chart/template change)
--from-file/--into→--in/--manifest, and add the required--scope fuzefront/fuzefront-secrets.Zoho→ZeptoMail(values-prod.yamlalready setshost: smtp.zeptomail.com; the prose was stale) + accurate "where to get the credentials".sealed-secrets.fuzeinfra.fuzefront.com→sealed-secrets.prod.fuzefront.com(the script's own comment notes the old host no longer resolves).rollout restartto force it).What this does NOT do
It does not resolve #500's acceptance criteria. The actual fix — sealing the real ZeptoMail
SMTP_USER/SMTP_PASSintodeploy/contabo/sealed/fuzefront-secrets.yaml— is owner-only: it needs the real credentials + the sealing cert, and per repo policy (and safety) those values are never handled by an agent, pasted into a PR, or committed in plaintext. This PR makes the owner's one-command path actually work. #500 stays open until the keys are sealed and the pod reachesRunning.Verified: no app code / Helm template changes; the Deployment (
email-service.yaml) andvalues-prod.yamlare already wired correctly.Refs #500.
Co-Authored-By: Claude claude-opus-4-8 noreply@anthropic.com