The change is not being applied because of incorrect YAML indentation in your kustomization.yaml file.

In the images list, the newName and newTag fields should have the same indentation level as the name field. The YAML parser is likely ignoring these fields due to the extra indentation.

Here is the corrected snippet for your images section:

// ...existing code...
images:
  - name: timescaledb/timescaledb-ha
    newName: demo.azurecr.io/timescaledb-ha
    newTag: timescaledb-ha:pg17.5-ts2.20.1
  - name: docker.io/bitnami/redis
    newName: demo.azurecr.io/redis
    newTag: 7.4.3-debian-12-r0
  - name: docker.io/bitnami/redis-sentinel
    newName: demo.azurecr.io/redis-sentinel
    newTag: 7.4.3-debian-12-r0

After correcting the indentation for all entries in the images list, running kubectl kustomize should apply the image overrides as expected.

You are right to point that out. My apologies. Looking closer at your kustomization.yaml, the indentation in the images section is indeed correct.

The issue is likely that another patch is overriding the image specification. Specifically, the patch patches/cluster.yaml is a likely candidate since your comment indicates it changes “the used image and domain names”.

When both an images transformation and a patches entry target the same field (like the image of a container), the patches directive takes precedence.

To resolve this, you should either:
1. Remove the image override from patches/shiny.yaml and rely solely on the images block.
2. Remove the timsescaledb/timescaledb-ha entry from the images block and ensure the correct image is specified within patches/cluster.yaml.

The first approach is generally cleaner for managing image tags across environments.

You are correct. My apologies for the oversight. Since the image key in cluster.yaml is commented out, it is not the cause of the issue.

The problem is that the images transformer in Kustomize does not know how to modify the image for the CNPG Custom Resource (CR). The images transformer typically works on standard Kubernetes kinds like Deployment, StatefulSet, etc., by looking for a standard image path. The CNPG CRD uses a spec.imageName field, which Kustomize doesn’t recognize by default.

To solve this, you need to tell Kustomize how to find and replace the image in your CNPG CR. You can do this by adding a configurations block to your kustomization.yaml.

Alternatively, and more simply, you can uncomment and use the image field directly in your patch file. This is the standard way to configure the image for the CNPG instance via its CR.

Here is the change for cluster.yaml:

// ...existing code...
  imageName: demo.azurecr.io/timescaledb-ha:pg17.5-ts2.20.1
  instances: 3

By uncommenting that line, you are explicitly setting the image that the CNPG Operator should use for the deployment it manages. This will override any default image set in the base and ensure the correct image from your Azure Container Registry is used. You can then remove the corresponding timescaledb/timescaledb-ha entry from the images section in your kustomization.yaml as it is no longer needed.

Of course. To make the images transformer in Kustomize aware of the image field in your CNPG custom resource, you need to create a configuration file that defines the path to that field.

Here’s how you can do it: 1. Create a kustomizeconfig.yaml file. This file will tell Kustomize where to find the image field in a CNPG resource. Place this file in the same directory as your kustomization.yaml.

// filepath: overlays/dev/database/kustomizeconfig.yaml
images:
- path: spec/imageName
  group: postgresql.cnpg.io
  kind: Cluster
  version: v1

Reference the configuration in your kustomization.yaml Add a configurations field to your main kustomization.yaml to point to the new configuration file.

// filepath: overlays/dev/database/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

configurations:
  - kustomizeconfig.yaml

resources:
// ...existing code...

With these two changes, Kustomize will now correctly apply the image replacement you’ve defined in the images section of your kustomization.yaml to the CNPG resource. You can keep the image line commented out in cluster.yaml.

This error means you are trying to patch/update a Kubernetes Job, but the Pod template (spec.template) is immutable after the Job is created. Kubernetes does not allow you to change the Pod spec of an existing Job (unlike Deployments).

Key part of the error:

Why does this happen?

When you change things like the container image, commands, env vars, etc. in a Job’s spec and try to kubectl apply or helm upgrade, Kubernetes refuses because it can’t safely update running/completed Jobs this way.

How to fix?

Delete the existing Job before applying the new version.

You can do this with:

kubectl delete job populate-db-service-data -n lethaldrifter-staging
kubectl delete job trackers-database-build-tables-load-geo-data -n lethaldrifter-staging

Then re-apply your manifests or re-run your Helm upgrade.

Note:

• If your Job is managed by Helm, Helm will usually handle this for you if you use helm upgrade –force, but this will delete and recreate the Job.
• If you want to keep logs or results, back them up before deleting.

Summary:
You can’t patch the Pod spec of a Job. Delete and recreate it instead.

You have reached your usage limit, try again later.

To meet all those patterns, you can use the following regex replacement rule:

✅ Regex pattern (match):

^/files(?:/([^/].*[^/])/?|/?$)

✅ Replacement string:

/$1

💡 Explanation: - ^/files matches the start of the path. - (?: … ) is a non-capturing group. - /([^/].*[^/])/? captures a subpath that doesn’t start or end with / (to avoid double slashes). - |/?$ matches /files or /files/ (end of input). - $1 in the replacement inserts the captured subpath (if any), or nothing if it’s just /files or /files/.

🔁 Results:

Input Output - /files / - /files/ / - /files/logos /logos/ - /files/logos/ /logos/ - /files/logos/pic.jpg /logos/pic.jpg - /files/text /text/ - /files/text/story.txt /text/story.txt

Let me know what language or tool you’re using this in (e.g., Python, JavaScript, Nginx), and I can tailor the syntax or escaping if needed.

To get a list of all container images (including registry, name, and tag) used by a set of Kubernetes pods, you can use the following kubectl command:

kubectl get pods -A -o jsonpath="{range .items[*].spec.containers[*]}{.image}{'\n'}{end}" | sort | uniq

Explanation:

-A: Lists pods in all namespaces. You can omit or change this to -n for a specific namespace.

-o jsonpath=…: Extracts just the .image field from each container spec.

sort | uniq: Removes duplicates and sorts the list.

Here are the views created in 04_02_create_view_core.sql

Materialized views

activity_count_by_hex_by_date
activity_count_by_hex
geosinks
hex_polygons
edge_list
hulls

Regular (non-materialized) views
hulls_live
activity_count

If you want them in SQL CREATE-order or as a one-line comma-separated list, tell me which format.

DROP MATERIALIZED VIEW IF EXISTS activity_count_by_hex_by_date CASCADE;
DROP MATERIALIZED VIEW IF EXISTS activity_count_by_hex CASCADE;
DROP MATERIALIZED VIEW IF EXISTS geosinks CASCADE;
DROP MATERIALIZED VIEW IF EXISTS hex_polygons CASCADE;
DROP MATERIALIZED VIEW IF EXISTS edge_list CASCADE;
DROP MATERIALIZED VIEW IF EXISTS hulls CASCADE;

DROP VIEW IF EXISTS hulls_live CASCADE;
DROP VIEW IF EXISTS activity_count CASCADE;

CASCADE only removes objects that depend on the exact object you drop. Timescale continuous aggregates, background jobs and other views can create additional dependencies that prevent a single DROP from succeeding. Remove related policies/jobs and then drop dependents bottom-up (or drop the top-level dependents explicitly).

Run these checks and commands in psql as a superuser.

Find timescale jobs referring to the view and delete them:

SELECT job_id, application_name, proc_name, config
FROM timescaledb_information.jobs
WHERE config::text ILIKE '%activity_count%';

-- for each job_id returned:
SELECT delete_job(<job_id>);

Remove continuous aggregate policy (if any):

SELECT remove_continuous_aggregate_policy('activity_count');

Inspect direct dependents (optional):

SELECT
  dependent_ns.nspname || '.' || dependent.relname AS dependent,
  obj_ns.nspname || '.' || obj.relname AS object,
  dependent.relkind
FROM pg_depend d
JOIN pg_class dependent ON d.objid = dependent.oid
JOIN pg_class obj ON d.refobjid = obj.oid
JOIN pg_namespace dependent_ns ON dependent.relnamespace = dependent_ns.oid
JOIN pg_namespace obj_ns ON obj.relnamespace = obj_ns.oid
WHERE obj.relname = 'activity_count_by_geohash_8_by_date';