Currently, we are using the staging image: us-central1-docker.pkg.dev/k8s-staging-images/dra-driver-cpu/dra-driver-cpu:latest in install.yaml. Staging registries have a 90-day retention policy. While this may work if releases happen frequently, it is not guaranteed and introduces risk if the release cadence slows down. The first release image has already been promoted to the production registry for example
skopeo list-tags docker://registry.k8s.io/dra-driver-cpu/dra-driver-cpu
{
"Repository": "registry.k8s.io/dra-driver-cpu/dra-driver-cpu",
"Tags": [
"sha256-0ab4277b74a88655b3a344e1939551f815d9729f971459dafef94a4642da4c71.sig",
"sha256-2c3eedbe4c9eed789d15c48cb92ab0b81969e30582098927bc0f8bac6310a535.sig",
"sha256-2f81cbd98adbb24e0f9cb19fef432a80eeacde839cb35af1d41c279d8530182d.sig",
"sha256-3b1ae241c65ed73381e1518e19ef996596086ae77f201d81e8bc1d35a6caae29.sig",
"sha256-a74bef2b40dff4e0aeabe247bd6513152d013932749f8d32c0e39e5e8fb810af.att",
"sha256-a74bef2b40dff4e0aeabe247bd6513152d013932749f8d32c0e39e5e8fb810af.sig",
"v0.1.0"
]
}
We could switch to versioned tags, but that would require updating manifests on every release. As an alternative, we could also promote the latest tag alongside versioned tags in the production registry, like below
diff --git a/registry.k8s.io/images/k8s-staging-dra-driver-cpu/images.yaml b/registry.k8s.io/images/k8s-staging-dra-driver-cpu/images.yaml
index d7a5ab916..8bad6f638 100644
--- a/registry.k8s.io/images/k8s-staging-dra-driver-cpu/images.yaml
+++ b/registry.k8s.io/images/k8s-staging-dra-driver-cpu/images.yaml
@@ -1,3 +1,3 @@
- name: dra-driver-cpu
dmap:
- "sha256:a74bef2b40dff4e0aeabe247bd6513152d013932749f8d32c0e39e5e8fb810af": ["v0.1.0"] # promote
+ "sha256:a74bef2b40dff4e0aeabe247bd6513152d013932749f8d32c0e39e5e8fb810af": ["latest", "v0.1.0"] # promote
This would allow us to safely use:
diff --git a/manifests/base/daemonset-dracpu.part.yaml b/manifests/base/daemonset-dracpu.part.yaml
index a094e34..c0636dc 100644
--- a/manifests/base/daemonset-dracpu.part.yaml
+++ b/manifests/base/daemonset-dracpu.part.yaml
@@ -82,7 +82,7 @@ spec:
- /dracpu
- --v=4
- --cpu-device-mode=grouped
- image: us-central1-docker.pkg.dev/k8s-staging-images/dra-driver-cpu/dra-driver-cpu:latest
+ image: registry.k8s.io/dra-driver-cpu/dra-driver-cpu:latest
instead of relying on staging images.
This change isn't big, just updating images.yaml in k8s.io and pointing to the production image in the install.yaml(base of it) is enough.
Would this approach be acceptable? Any objections @ffromani @pravk03 ?
Currently, we are using the staging image:
us-central1-docker.pkg.dev/k8s-staging-images/dra-driver-cpu/dra-driver-cpu:latestin install.yaml. Staging registries have a 90-day retention policy. While this may work if releases happen frequently, it is not guaranteed and introduces risk if the release cadence slows down. The first release image has already been promoted to the production registry for exampleWe could switch to versioned tags, but that would require updating manifests on every release. As an alternative, we could also promote the latest tag alongside versioned tags in the production registry, like below
This would allow us to safely use:
instead of relying on staging images.
This change isn't big, just updating images.yaml in k8s.io and pointing to the production image in the install.yaml(base of it) is enough.
Would this approach be acceptable? Any objections @ffromani @pravk03 ?