helm!: create unified chart - #122
Conversation
CL-SHLOMIKONCHA
left a comment
There was a problem hiding this comment.
Also we need it to publish the new "common" pycsw to dedicated common/pycsw docker and helm/common/pycsw helm path by the existing workflows
| @@ -0,0 +1,6 @@ | |||
|
|
|||
| # pycsw custom uwsgi settings injected into root location | ||
| uwsgi_pass {{ include "pycsw.service.fullname" . }}:{{ .Values.servicePort }}; | ||
| include uwsgi_params; | ||
| uwsgi_hide_header Set-Cookie; |
There was a problem hiding this comment.
do we need it
current nginx (2.2.1) includes "blacklist headers"
There was a problem hiding this comment.
These strip the Set-Cookie response header and blank the inbound Cookie sent to the uwsgi upstream. Does nginx 2.2.1's blacklist-headers cover both the response Set-Cookie and the request Cookie? If it covers both I'll drop lines 5-6; if it's response-headers only I'll keep uwsgi_param HTTP_Cookie "".
There was a problem hiding this comment.
Checked auth.js. Its DENYLIST (incl. cookie) is applied by filterHeaders, which only builds the OPA authz subrequest body (input.headers) — and only on the OPA path. It doesn't strip Cookie from the request forwarded to the pycsw upstream, and touches no response headers at all.
So neither line here is covered by it:
uwsgi_hide_header Set-Cookie;— strips the response header from the upstream; auth.js never touches responses.uwsgi_param HTTP_Cookie "";— blanksCookieto the uwsgi upstream; the denylist only filters what's sent to OPA, not upstream.
Keeping both.
| Create service name as used by the service name label. | ||
| */}} | ||
| {{- define "pycsw.service.fullname" -}} | ||
| {{- printf "%s-%s-%s" .Release.Name (include "pycsw.name" .) "service" }} |
There was a problem hiding this comment.
Can we just replace the "(include "pycsw.name" .) to .Chart.Name for each of those resources?
example:
| {{- printf "%s-%s-%s" .Release.Name (include "pycsw.name" .) "service" }} | |
| {{- printf "%s-%s-%s" .Release.Name .Chart.Name "service" }} | |
There was a problem hiding this comment.
Keeping pycsw.name here. This PR adds nameOverride support (see _helpers.tpl:6-8 and the values comment) so multiple aliased instances can deploy in one release without resource-name collisions. .Chart.Name is fixed to pycsw, which would break that. pycsw.name returns .Chart.Name by default and only differs when nameOverride is set.
| {{ end }} | ||
| uwsgi.ini: {{ tpl (.Files.Get "config/pycswWsgi.ini") . | quote }} | ||
| CORS_ENABLED: {{ .Values.env.cors.enabled | quote }} | ||
| CORS_ALLOWED_HEADERS: {{ include "pycsw.cors.allowedHeaders" . | default (quote "") }} |
There was a problem hiding this comment.
does includes works as template? currently were using template for this allowHeaders render
There was a problem hiding this comment.
include returns the rendered string, so it can be piped — here into | default (quote ""). template is an action that writes directly to output and can't be piped, so it wouldn't work in this expression. Keeping include.
There was a problem hiding this comment.
Why do you need to usetemplate? It should be * by default, today nginx handles the cors.
| nameOverride: "" | ||
|
|
||
| # REQUIRED: name of a ConfigMap provided by the consuming chart, containing the keys: | ||
| # pycsw.cfg - the pycsw configuration file |
There was a problem hiding this comment.
Where will these files be found? (pycsw.cfg + mapping.py)
There was a problem hiding this comment.
From the ConfigMap named by existingConfigmap, provided by the consuming chart (documented at values.yaml:41-45). The deployment mounts its pycsw.cfg and mappings.py keys as files (see the volumes in deployment.yaml).
| the pycsw.cfg and mappings.py keys. The value may itself be a template. | ||
| Fails rendering when not provided. | ||
| */}} | ||
| {{- define "pycsw.teamConfigmapName" -}} |
There was a problem hiding this comment.
I would suggest to change this teamConfigmapName same on existingConfigmap
There was a problem hiding this comment.
Renamed pycsw.teamConfigmapName → pycsw.existingConfigmapName (helper + the $existingConfigmapName var in deployment.yaml).
| repository: common/nginx | ||
| # defaults to the nginx chart appVersion when empty | ||
| tag: "" | ||
| mclabels: |
There was a problem hiding this comment.
missing logScraping key - default to true
There was a problem hiding this comment.
Added logScraping: true under both mclabels and nginx.mclabels.
| tracing: | ||
| enabled: false | ||
| url: http://localhost:55681/v1/trace | ||
| metrics: |
There was a problem hiding this comment.
is that relevant ?
There was a problem hiding this comment.
currently, its defined within dem and raster helms
There was a problem hiding this comment.
mclabels.prometheus.{enabled,port} (values.yaml:33) already drives the prometheus scrape annotations via mclabels.annotations. The env.metrics.prometheus.{scrape,port} block in raster/dem looks legacy — no pycsw template reads it. Do you want it added for parity, or is the mclabels one sufficient? I lean toward mclabels-only to avoid duplication.
There was a problem hiding this comment.
See above — likely redundant with mclabels.prometheus, which already drives the scrape annotations here.
There was a problem hiding this comment.
Right, but there it's env.metrics.prometheus, which no pycsw template consumes. mclabels.prometheus covers the same purpose in this chart.
| enabled: true | ||
| # routesMapping must be set by the consuming chart, e.g. | ||
| # routesMapping: | ||
| # - path: /api/raster/v1 |
There was a problem hiding this comment.
avoid mention raster here
There was a problem hiding this comment.
Changed the example to /api/<domain>/v1.
There was a problem hiding this comment.
All the path that mentioned a team chart path are irrelevant, actually, i guess you would like to get rid of raster/dem/3d etc.. helm directories in this PR
There was a problem hiding this comment.
I wanted to seperate this:
#125
We can approve it and merge to this branch first if you want.
- remove leading empty line in pycsw-location.conf - rename pycsw.teamConfigmapName helper to pycsw.existingConfigmapName to align with the existingConfigmap value - add logScraping: true to mclabels and nginx.mclabels - genericize routesMapping example (raster -> <domain>) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The nginx config files were renamed config/pycsw-{location,server}.conf ->
config/{location,server}.conf but references still pointed at the old names,
breaking .Files.Get at render. Update values.yaml (fileName, extraVolumeMounts),
nginx-configmap keys/Files.Get, and README.
Verified: helm template renders clean; configmap emits location.conf/server.conf.
…b schema example - env.cors.allowedHeaders "x-api-key" -> "*" - comment out nginx.image.tag (falls back to nginx chart appVersion) - genericize env.db.schema example (drop raster-specific name) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
1.1.0 requires the new mclabels `criticality` field; set it to `customer` on both the pycsw and nginx mclabels blocks. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

No description provided.