DM-54393: Add czar external service template and ingest helper tini to Qserv Helm chart#1008
DM-54393: Add czar external service template and ingest helper tini to Qserv Helm chart#1008fritzm merged 2 commits intotickets/DM-43715from
tini to Qserv Helm chart#1008Conversation
fritzm
force-pushed
the
tickets/DM-54393
branch
from
bf7de83 to
e6e7a13
Compare
iagaponenko
left a comment
iagaponenko
left a comment
There was a problem hiding this comment.
LGTM, just a few questions and comments.
| python3.12 \ | ||
| python3.12-devel \ | ||
| jemalloc \ | ||
| tini \ |
There was a problem hiding this comment.
You already made this fix as well as set an explicit version of the nlohmann library in the previous PR: #1007
Did you cherry-pick this commit from the other PR?
There was a problem hiding this comment.
Yes. This commit should just drop out when this branch is rebased before merge.
| version: "2026.2.2-pre" | ||
| appVersion: "2026.2.2-pre" | ||
| version: 2026.3.2-pre | ||
| appVersion: "2026.3.2-pre" |
There was a problem hiding this comment.
Just for my own education. Is this the version number of the development branch of Qserv? Or, this is the version number of the chart?
There was a problem hiding this comment.
One of each :-)
version is the chart version
appVersion is the wrapped application (Qserv) version
Since our chart is in the application source tree and the two are always tagged/released simultaneously, these will always change in lock-step.
If we split the chart off into its own repo, it might be versioned/released independently of Qserv itself.
In practice, these numbers aren't terribly important, since we aren't doing independent chart releases to chart repositories. But I like to keep them more or less up to date so they aren't outright lies.
I think we have a little more thinking to do on how we want to update these (and default values.yaml container tags, etc.) as part of our release process.
| - 34.121.239.92/32 | ||
| - 134.79.0.0/16 | ||
| - 172.16.0.0/12 | ||
| - 172.24.49.51/32 |
There was a problem hiding this comment.
For my own education, are these the IP addresses on the SLAC network or on the internal Kubernetes network? If the former, then the next question - would it work at UKDF?
There was a problem hiding this comment.
Yes, these are SLAC/USDF and Google IDF. They are USDF-specific, and would need to be edited for UKDF, along with a few other items in the chart (storage class names, etc.)
We should shortly switch to having a "default" values.yaml, and then some site-specific ones. We need to decide whether or not we want to carry all that in the base Qserv repo. It doesn't feel quite "right", but if you recall, having separate repos like we had for a while with qserv-operator and qserv-injest was also confusing and painful...
| mariadbImageName: ghcr.io/lsst/qserv-mariadb:2026.2.2-rc1 | ||
| sslProxyImageName: qserv/mysql-proxy-ssl:latest | ||
| ingestHelperImageName: qserv/lite-build:2026.2.1-rc1-19-gf0e450b0e | ||
| ingestHelperImageName: ghcr.io/lsst/qserv-build-base:2026.2.2-rc1-46-gf129c37c1 |
There was a problem hiding this comment.
Just a minor comment - at some point (not in this PR) we should begin naming the development branch of Qserv similarly to how we do this in the production ("classic") version, e.g., 2026.3.2-pre.
fritzm
force-pushed
the
tickets/DM-43715
branch
from
cd627b8 to
a380735
Compare
fritzm
force-pushed
the
tickets/DM-54393
branch
from
e6e7a13 to
1b78cd7
Compare
fritzm
force-pushed
the
tickets/DM-43715
branch
from
a380735 to
c91abd6
Compare
fritzm
force-pushed
the
tickets/DM-54393
branch
from
1b78cd7 to
4c8c48f
Compare
2 participants
The Qserv Helm chart requires a czar “external” service template – this provides a place to hang load balancer annotations to permit access to czar http and mysqlproxy ports from outside the k8s cluster. One commit on this PR adds this.
A separate (unrelated) commit here changes the ingest helper template in the chart to use
tinias PID 1 in the ingest helper build base container. This provides signal handling so the ingest helper container exits in a timely fashion under k8s.A third commit adds
tiniitself to the build baseDockerfile; this commit should drop out when this PR is rebased afterDM-54392merges tomain.