Helm chart thunder - #33
Conversation
…s and console configuration
…ng and configuration
… scripts for streamlined deployment Co-authored-by: Copilot <copilot@github.com>
- Introduced `02-sample-resources.sh` to automate the creation of a SPA resource. - The script sources common functions and loads environment variables from a `.env` file. - It defines default parameters for the SPA and includes functions to extract JSON values, get organization unit IDs, and fetch flow IDs. - Implements the `create_spa_application` function to handle the API call for creating the SPA with necessary configurations. - Logs success or error messages based on the API response.
…rement Co-authored-by: Copilot <copilot@github.com>
Co-authored-by: Copilot <copilot@github.com>
…aven config script for OAUTHBEARER support Co-authored-by: Copilot <copilot@github.com>
Co-authored-by: Copilot <copilot@github.com>
Co-authored-by: Copilot <copilot@github.com>
Co-authored-by: Copilot <copilot@github.com>
- Introduced a new ConfigMap (`thunder-bootstrap`) to include bootstrap scripts for application provisioning. - Added `30-sample-resources.sh` script to log the completion of sample resources step. - Created `NOTES.txt` to provide installation and usage instructions for the silver-thunder chart. - Implemented helper functions in `_helpers.tpl` for consistent naming and labeling. - Updated `values.yaml` and `values.example.yaml` with necessary configurations for deployment and ingress.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request transitions the API server to mandatory HTTPS and replaces password-based SMTP authentication with XOAUTH2 token forwarding. It introduces support for multiple recipients via a new recipients array in the request body and updates the success response status to 202 Accepted. Additionally, a new umbrella Helm chart for WSO2 Thunder is added to the infrastructure. Feedback suggests merging global template data with per-recipient fields to preserve personalization and implementing parallel email delivery to improve performance for large recipient lists.
| func sendNotifyEmail(mailer emailer.Mailer, req notifyRequest, recipients []user) error { | ||
| var sendErrors []error | ||
|
|
||
| for _, recipient := range recipients { | ||
| if req.Template == "" { | ||
| if err := mailer.Send(recipient.Email, "welcome.tmpl", recipient); err != nil { | ||
| sendErrors = append(sendErrors, fmt.Errorf("recipient %s: %w", recipient.Email, err)) | ||
| } | ||
| continue | ||
| } | ||
|
|
||
| templateData := any(recipient) | ||
| if len(req.TemplateData) > 0 { | ||
| templateData = req.TemplateData | ||
| } | ||
|
|
||
| if err := mailer.SendWithCustomTemplate(recipient.Email, req.Template, templateData); err != nil { | ||
| sendErrors = append(sendErrors, fmt.Errorf("recipient %s: %w", recipient.Email, err)) | ||
| } | ||
| } | ||
|
|
||
| return errors.Join(sendErrors...) | ||
| } |
There was a problem hiding this comment.
In sendNotifyEmail, if req.TemplateData is provided, it completely overrides the per-recipient data (recipient struct) for custom templates. This means that personalization fields like {{.Name}} or {{.Email}} will not be available in the custom template unless they are manually included in req.TemplateData for every request. Consider merging the per-recipient data with req.TemplateData to allow both global and personalized fields in custom templates.
| for _, recipient := range recipients { | ||
| if req.Template == "" { | ||
| if err := mailer.Send(recipient.Email, "welcome.tmpl", recipient); err != nil { | ||
| sendErrors = append(sendErrors, fmt.Errorf("recipient %s: %w", recipient.Email, err)) | ||
| } | ||
| continue | ||
| } | ||
|
|
||
| templateData := any(recipient) | ||
| if len(req.TemplateData) > 0 { | ||
| templateData = req.TemplateData | ||
| } | ||
|
|
||
| if err := mailer.SendWithCustomTemplate(recipient.Email, req.Template, templateData); err != nil { | ||
| sendErrors = append(sendErrors, fmt.Errorf("recipient %s: %w", recipient.Email, err)) | ||
| } | ||
| } |
There was a problem hiding this comment.
Emails are currently sent sequentially in a loop. If the recipients list is large or the SMTP server is slow, this background task could take a significant amount of time to complete. Consider sending emails in parallel using goroutines and a synchronization primitive like errgroup.Group. This provides a localized concurrency improvement without the complexity of a full worker pool architecture, which can be deferred to a future PR.
References
- When a suggested change involves significant architectural refactoring (e.g., implementing a worker pool), it can be deferred to a future PR. A simpler, more localized solution (e.g., using a WaitGroup) can be used as an interim measure.
| @@ -0,0 +1,36 @@ | |||
| /** | |||
There was a problem hiding this comment.
I think we should remove this.
2 participants
Description
Adds an umbrella Helm chart that wraps the upstream WSO2 Thunder v0.32.0 chart and bakes this repo's bootstrap scripts into a ConfigMap, so installing Thunder on Kubernetes is a single
helm installmatching the rest of the mail-plane charts. The image (ghcr.io/asgardeo/thunder:0.32.0) matches the version pinned indocker-compose.yml.Type of Change
Changes Made
silver-thunderatmail-infra/helm/thunder/(Chart + values + README + values.example.yaml + .helmignore).thunderv0.32.0 chart verbatim undercharts/thunder/(sourced from thunder-id/thunderid @ v0.32.0/install/helm). Vendored because the upstream chart was never published to OCI at this version — the published OCI artifact (thunderid0.38.0+) was a later rename. Vendoring + arepository: "file://."no-op dependency entry keepshelm installa single command (nohelm dependency buildstep required)..helmignore. Added a smallVENDORED.mdsentinel insidecharts/thunder/explaining provenance and pointing back at the umbrella's README.templates/bootstrap-configmap.yamlrenders this repo'smail-infra/scripts/thunder/01-default-resources.shand02-sample-resources.sh(copied intofiles/as20-and30-prefixed scripts) into aConfigMapnamedthunder-bootstrapvia(.Files.Glob "files/*.sh").AsConfig.pre-install,pre-upgradeHelm hook at weight-10(matches the upstream's ownsetup-config-map/bootstrap-configmap), so it's created before the setup Job (pre-installhook at weight-5) tries to mount it. Without this, the Job'sMountVolume.SetUp failed for volume "bootstrap-scripts" : configmap "thunder-bootstrap" not foundand Helm rolled back the entire release.values.yamloverrides the subchart's defaults under thethunder:key for a working SQLite-on-minikube install:deployment.replicaCount: 1,securityContext.readOnlyRootFilesystem: false,hpa.enabled: false(SQLite is single-writer, no autoscale).config,runtime,user,consent) switched from the chart's Postgres default to SQLite. The consent database had to be wired explicitly — without it the OpenFGC consent server crash-loops withdial tcp [::1]:5432: connect: connection refused.persistence.enabled: true(PVC for SQLite data).bootstrap.configMap.name: thunder-bootstrap+files: [20-default-resources.sh, 30-sample-resources.sh](Pattern 2 — additive to the chart's built-in10-*defaults).ghcr.io/asgardeo/thunder:0.32.0to matchdocker-compose.yml.common.shalready providesthunder_api_call(the rename tothunderid_api_callonly happened in 0.38.0+), so no shim is needed.values.yamldo I edit?" table, the bootstrap script ordering, how to update the vendored subchart (singlecurl … | tar -xz+cp -R), and how to access the running pod (port-forward for local minikube / cluster-internal DNS for the other mail-plane charts).Testing
helm lint mail-infra/helm/thunder→ 0 errors, 0 warnings.helm template thunder ./mail-infra/helm/thunder --namespace pingmailer→ 17 resources rendered (16 from the vendored subchart + 1 umbrellathunder-bootstrapConfigMap), all 3image:lines =ghcr.io/asgardeo/thunder:0.32.0, renderedconsent-deployment.yamlshowstype: "sqlite"(no Postgres dial).helm.sh/hook: pre-install,pre-upgrade,helm.sh/hook-weight: "-10".ghcr.io/asgardeo/thunder:0.32.0):helm upgrade --install thunder ./mail-infra/helm/thunder -n pingmailer --create-namespace -f my-thunder-values.yamlthunder-bootstrap+ upstream config-maps land first;thunder-setupJob runs, executes the chart's10-*scripts + this repo's20-default-resources.sh(creates default OU, person schema, admin user, system resource server, system action, admin role, CONSOLE app) +30-sample-resources.sh(no-op). Job exits 0.thunder-deploymentpod runs, both daemons (Consent Serveron:9090,Thunder Serveron:8090) start cleanly. Health endpoints return 200 (/health/liveness,/health/readiness).kubectl -n pingmailer port-forward svc/thunder-service 8090:8090+curl -k https://localhost:8090/health→ 200 OK.failed pre-install: timed out waiting for the condition, ConfigMap not found) — fix verified by re-installing with the hook annotations in place.Checklist
Related Issues
Fixes #