Tilt: Changes to PostgresVersion image don't propagate to Postgres resource

[tamer-hassan]

for example, while trying to integrate with KubeDB custom PostgresVersion

apiVersion: catalog.kubedb.com/v1alpha1
kind: PostgresVersion
metadata:
  name: postgis-2.5.2
spec:
  version: 9.6
  db:
    image: "localhost:32001/postgres:postgis-2.5.2"
  exporter:
    image: "kubedb/postgres_exporter:v0.4.7"
  tools:
    image: "kubedb/postgres-tools:9.6-v3"

The image name is mistakenly determined as "postgis-2.5.2" instead of "postgres:postgis-2.5.2"

[landism]

Sorry you've run into trouble with this!

I suspect our expectations of how people would use this aren't quite matching what you're doing. Can you explain what you're trying to do - how you observed that the image name is determined as "postgis-2.5.2", and why you want it to be determined as "postgres:postgis-2.5.2"?

The behavior I'd expect is:
Tilt determines the image name is localhost:32001/postgres, and, if you specify a docker_build('localhost:32001/postgres), that docker build would have its image inserted into this yaml with a tilt tag (i.e.,kubectl get postgis-2.5.2would show the image as something likelocalhost:32001/postgres:tilt-bdb87344c22c60b5`, which had just been built by tilt).

I think I've confirmed this is behaving as expected in a little Tiltfile here. Does that look like what you're doing?

[tamer-hassan]

Some background info:

1. I needed to run KubeDB with custom Postgres (to include Postgis extension)
2. I already have defined CRD yamls for PostgresVersion & Postgres, since I needed Postgres 9.6 + Postgis 2.5.2 together, per this doc: https://kubedb.com/docs/0.12.0/guides/postgres/custom-versions/setup/
3. Pushing built image to kind-local registry, based on https://github.com/windmilleng/kind-local
   so Tiltfile begins with something like:

docker_build('localhost:32001/postgres:postgis-2.5.2', './kubedb/postgres',
  dockerfile='./kubedb/postgres/Dockerfile')

An example postgresversion.yaml (per the postgres custom-versions doc above)

apiVersion: catalog.kubedb.com/v1alpha1
kind: PostgresVersion
metadata:
  name: postgis-2.5.2
spec:
  version: 9.6
  db:
    image: "localhost:32001/postgres:postgis-2.5.2"
  exporter:
    image: "kubedb/postgres_exporter:v0.4.7"
  tools:
    image: "kubedb/postgres-tools:9.6-v3"

and finally the postgres.yaml

apiVersion: kubedb.com/v1alpha1
kind: Postgres
metadata:
  name: postgis-postgres
spec:
  version: "postgis-2.5.2" # points to the name of our custom PostgresVersion
  storage:
    storageClassName: "standard"
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: 3Gi

[landism]

my understanding of the situation:

postgis-postgress here is an instance of the Postgres CRD. It doesn't quite fit into how Tilt handles CRDs, because Tilt expects images to be specified in the instance of the CRD, but it's actually getting the version from a separate object (the PostgresVersion).

Since the image name is only specified in the PostgresVersion, we could theoretically make this work with k8s_kind('PostgresVersion', image_json_path='{.spec.db.image}').

However, kubedb's controller for Postgres appears to get the image name from PostgresVersion whenever a Postgres object changes, and then doesn't react when we change the image name in PostgresVersion.

Options I see:

1. Add functionality allowing Tilt to change the PostgresVersion's name and update Postgres's {.spec.version} to match after every build. I have not put much thought into this and have no immediate ideas on how general a solution would be appropriate here or what this might look like in the Tiltfile. I don't know if we have other, similar use cases to inform this.
2. change kubedb's controller to respond to changes to PostgresVersion. This might be hard and/or controversial.

Either way, I don't think we have a short-term solution to this problem.

[nicks]

I updated the title to better reflect the problem here. ya, i think that analysis is right. Kubedb is widespread enough that it might make sense to hardcode strategy (1) until we figure out a more general way to do this..

[nicks]

Someone in the kubedb slack channel suggested a third strategy: Tilt could be smart enough to detect when there's a statefulset around with the old image, and manually delete it. The KubeDB controller should be smart enough to replace it with the new image.