So, if I understand the code correctly, what was happening is that now the latest edge and the one we pin in the charm do not coincide anymore, therefore it was taking long time to download the image, right? I'm wondering whether we should actually use the same image that we use for kyuubi (for which we pin the hash) also in the pod template.
I wouldn't block this PR, as this already fix the problem (here the approve!). Also maybe we could factor in the point above when we will also refactor kyuubi tests to use the spark-k8s-bundle fixtures
I am not exactly sure why the image pulling process is taking a bit longer than it used to before, but the reason you mentioned is definitely very plausible. However, since kubectl apply returns immediately while the container is still being created, I added the wait step to handle cases where it would take more time.
I agree with using the same image pinned everywhere we use our rock image (unless we explicitly need pod image to be different from the charm image). We might need to hardcode this hash at multiple places (eg, pod spec, metadata.yaml of charm, etc.) but at the moment I don't see a workaround for that.
I am not exactly sure why the image pulling process is taking a bit longer than it used to before, but the reason you mentioned is definitely very plausible. However, since
kubectl applyreturns immediately while the container is still being created, I added thewaitstep to handle cases where it would take more time.I agree with using the same image pinned everywhere we use our rock image (unless we explicitly need pod image to be different from the charm image). We might need to hardcode this hash at multiple places (eg, pod spec, metadata.yaml of charm, etc.) but at the moment I don't see a workaround for that.