suite: Check for existence of container images #2104
Conversation
zmc
commented
Nov 6, 2025
zmc
commented
- At schedule time, actually check for the existence of a container image rather than for a completed package build
- Provide some helper functions so that tasks can locate images based on sha1/distro/flavor
zmc
requested review from
amathuria and
kamoltat
and removed request for
a team
adk3798
left a comment
adk3798
left a comment
There was a problem hiding this comment.
Seems like it builds all the names and things properly. I assume we'll have to have the cephadm task make use of this? Right now it looks like we just get the sha1 from the config and append it as the image tag to some default image base
zmc
force-pushed
the
container-images
branch
2 times, most recently
from
343c239 to
0a6690b
Compare
As opposed to checking for a specific completed package build, and inferring the status of the container based on the result. This check will only affect jobs which use the cephadm task. Signed-off-by: Zack Cerza <zack@cerza.org>
Signed-off-by: Zack Cerza <zack@cerza.org>
I've just pushed a commit that causes teuthology to inspect any cephadm task invocations it finds, and check images mentioned there as well. This is in addition to It checking for the existence of the default image. |
| @functools.lru_cache() | ||
| def container_image_exists(image: str): | ||
| """ | ||
| Use the Quay API to check for the existence of a container image. |
There was a problem hiding this comment.
Shouldn't this code work for any container registry api? If so, the description is better to change.
There was a problem hiding this comment.
Should it? I'm not sure that is the case, but if you have a reference I would love to see it
There was a problem hiding this comment.
I thought this method supposed to be working with other registry as well as ceph itself. For example, downstream teuthology deploys fine cephadm using third party container registry, but if we merge this quay only specific check it might break this. So, we either support some universal api or we need to check if we actually can check the existence of the container.
There was a problem hiding this comment.
Which downstream product an which non-quay registry?
I can tweak this so that it skips the check if, for example, the host portion of the image locator doesn't contain 'quay', and then interested parties can contribute checks using APIs they need to query
