OKD-379: Fix missing namespace in database template image triggers#701
OKD-379: Fix missing namespace in database template image triggers#701pskrbasu wants to merge 1 commit into
Conversation
When database templates were migrated from DeploymentConfig to Deployment
(openshift/library commit f865a9e2), the image.openshift.io/triggers
annotation dropped the namespace field from the ImageStreamTag reference.
Without an explicit namespace, the image trigger controller defaults to the
Deployment's own namespace instead of 'openshift', causing image resolution
to fail. The container image stays as ' ' (a single space), which Kubernetes
rejects with: spec.containers[0].image: Invalid value: " ": must not have
leading or trailing whitespace.
Fix: Add "namespace":"${NAMESPACE}" to the trigger annotation's from
object in all 12 affected OKD database templates. The NAMESPACE parameter
already exists in every template (default: 'openshift').
Additional fixes:
- dancer-mysql-example: Add missing image trigger annotation and
MYSQL_VERSION parameter to the database Deployment
- mysql-persistent: Remove stray image.openshift.io/triggers annotation
from the Service object (copy-paste error referencing MARIADB_VERSION)
Only okd-x86_64 assets are changed — OCP templates are not affected.
Fixes: okd-project/okd#2337
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository: openshift/coderabbit/.coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
TestingValidated end-to-end on a live OKD 4.22.0-okd-scos.4 cluster ( 1. Reproduced the bug (before fix)No pods were created. The image stayed as 2. Applied the fixPaused the cluster-samples-operator to prevent it from overwriting our template changes: Then replaced all 12 fixed templates in the 3. Verified the fix — all 4 database typesImage resolution — all resolved to real registry refs (no more All pods Running and Ready: Database connectivity verified: 4. Cleanup |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: pskrbasu The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
@pskrbasu: This pull request references OKD-379 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the bug to target the "4.22.0" version, but no target version was set. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
@pskrbasu: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
|
@pskrbasu for this change to take effect you need to fix it where the openshift/library is syncing those templates, for example on the cakephp template it needs to be fixed here https://github.com/sclorg/cakephp-ex/blob/master/openshift/templates/cakephp-mysql.json#L306 |
Problem
Deploying databases (PostgreSQL, MySQL, MariaDB, Redis) from the Software Catalog on OKD 4.22 fails with:
Reported in okd-project/okd#2337
Root Cause
When database templates were migrated from
DeploymentConfigtoDeployment(openshift/library@f865a9e2, Dec 2023), theimage.openshift.io/triggersannotation on database Deployments dropped thenamespacefield from theImageStreamTagreference.The old
DeploymentConfigtrigger had:{"from": {"kind": "ImageStreamTag", "name": "postgresql:${POSTGRESQL_VERSION}", "namespace": "${NAMESPACE}"}}The new
Deploymentannotation was missingnamespace:{"from": {"kind": "ImageStreamTag", "name": "postgresql:${POSTGRESQL_VERSION}"}}Without an explicit namespace, the image trigger controller defaults to the Deployment's own namespace (the user's project) instead of
openshift. Since database ImageStreams live in theopenshiftnamespace, the lookup fails and the container image is never resolved — it stays as" "(a single space placeholder). Kubernetes then rejects the pod with the whitespace validation error.Fix
Add
"namespace": "${NAMESPACE}"to thefromobject in theimage.openshift.io/triggersannotation on all affected database Deployments. TheNAMESPACEparameter already exists in every template with a default value of"openshift", so no new parameters are needed.Templates fixed (11 files — namespace added to trigger):
postgresql-persistentpostgresql:${POSTGRESQL_VERSION}postgresql-ephemeralpostgresql:${POSTGRESQL_VERSION}mysql-persistentmysql:${MYSQL_VERSION}mysql-ephemeralmysql:${MYSQL_VERSION}mariadb-persistentmariadb:${MARIADB_VERSION}mariadb-ephemeralmariadb:${MARIADB_VERSION}redis-persistentredis:${REDIS_VERSION}redis-ephemeralredis:${REDIS_VERSION}cakephp-mysql-examplemysql:${MYSQL_VERSION}cakephp-mysql-persistentmysql:${MYSQL_VERSION}dancer-mysql-persistentmysql:${MYSQL_VERSION}Additional fixes:
dancer-mysql-example: The database Deployment had"image": " "but was entirely missing theimage.openshift.io/triggersannotation — image resolution could never fire. Added the trigger annotation with namespace. Also added the missingMYSQL_VERSIONparameter (default"8.0-el8").mysql-persistent: Removed a strayimage.openshift.io/triggersannotation from the Service object. It was a copy-paste error that referenced${MARIADB_VERSION}— Services don't have containers, so this annotation had no effect but was incorrect.OCP impact: None
All changes are under
assets/operator/okd-x86_64/only. OCP Dockerfiles (Dockerfile,Dockerfile.rhel7) copy fromocp-x86_64/ocp-s390x/ocp-ppc64le/ocp-aarch64. OnlyDockerfile.okdcopies fromokd-x86_64. The two directory trees are completely separate.