[BUG] Test for SCS-0104 fails for other image source

[mauhau]

The source of images is checked to be with prefixes documented as examples.

We added our prefix to the test but imho the test should only validate if the source is set to a correct url.

diff --git a/Tests/iaas/scs_0104_standard_images/standard_images.py b/Tests/iaas/scs_0104_standard_images/standard_images.py
index 6f8c827..4c35cf1 100644
--- a/Tests/iaas/scs_0104_standard_images/standard_images.py
+++ b/Tests/iaas/scs_0104_standard_images/standard_images.py
@@ -13,6 +13,7 @@ _specs = yaml.safe_load(r"""
   source:
   - https://swift.services.a.regiocloud.tech/swift/v1/AUTH_b182637428444b9aa302bb8d5a5a418c/openstack-k8s-capi-images/ubuntu-2404-kube
   - https://swift.services.a.regiocloud.tech/swift/v1/AUTH_b182637428444b9aa302bb8d5a5a418c/openstack-k8s-capi-images/ubuntu-2204-kube
+  - https://repo.uhurutec.io/content/umetal/k8s-node-images
 "ubuntu-capi-image-2":
   # this name_scheme uses `-` to separate base name "ubuntu-capi-image" from version
   # latest openstack-image-manager can be told to use `-` by setting `separator: "-"` on the image
@@ -20,6 +21,7 @@ _specs = yaml.safe_load(r"""
   source:
   - https://swift.services.a.regiocloud.tech/swift/v1/AUTH_b182637428444b9aa302bb8d5a5a418c/openstack-k8s-capi-images/ubuntu-2404-kube
   - https://swift.services.a.regiocloud.tech/swift/v1/AUTH_b182637428444b9aa302bb8d5a5a418c/openstack-k8s-capi-images/ubuntu-2204-kube
+  - https://repo.uhurutec.io/content/umetal/k8s-node-images
 "Ubuntu 24.04":
   source:
   - https://cloud-images.ubuntu.com/releases/noble/

[mbuechse]

I don't see the bug here? The standard clearly states that the image source must begin with one of the prefixes -- and you're not supposed to amend the list!

[mbuechse]

Addendum: also, either your image is identical with the one from regiocloud.tech -- and then you can use the corresponding prefix --, or it isn't identical, and then you may not use the namescheme anyway.

[mauhau]

This is still a bug.

1. The CAPI images for all Kubernetes versions cannot be pulled from regiocloud anymore:

maha@maha-lap-04:/home/maha$ curl https://swift.services.a.regiocloud.tech/swift/v1/AUTH_b182637428444b9aa302bb8d5a5a418c/openstack-k8s-capi-images/ubuntu-2204-kube ; echo
NoSuchKey

2. The standard always reflects the yaml field image_source. In all examples there is just a field source.

3. In the standard the CAPI images are just shown as Example and furthermore CAPI images sometimes have a regex "ubuntu-capi-image v[0-9]\\.[0-9]+(\\.[0-9]+)?" (no - before v) and sometimes "ubuntu-2204-kube-v[0-9].[0-9]+(.[0-9]+)?"

Where can we find the definite requirements to match against? And where and how can we download all CAPI images to fit the standard?

[mbuechse]

1. The real URL needs to be a little longer than the prefix. I wouldn't expect the prefix to work, it doesn't even have the filename extension.
2. image_source is the name of the metadata field in Glance; source is the field in the yaml file for the test suite.
3. The standard only describes the yaml file for the test suite. It doesn't tell you how to build the image.

Version 1 of the standard is not great; it's too complicated. Version 2 is not yet effective, but it may be the better way of approaching the topic, so I recommend reading that one: https://docs.scs.community/standards/scs-0104-v2-standard-images

And if you need an example for how to build the image, see here: D'oh, I wanted to refer you to the file in the openstack-image-manager repo, but I can't seem to find it. @berendt Do you folks have an image-manager yaml for the CAPI images as well?

[mbuechse]

I did find this one: https://github.com/osism/k8s-capi-images/blob/main/.images.yml
but it's hopelessly outdated.

[berendt]

We have not been publishing the images at https://swift.services.a.regiocloud.tech for quite some time now, but rather at https://nbg1.your-objectstorage.com. Old versions are still available there (https://swift.services.a.regiocloud.tech/swift/v1/AUTH_b182637428444b9aa302bb8d5a5a418c/openstack-k8s-capi-images/). That's why I don't think the URL makes any sense. The images we build are only one possible source for CAPI images. In most environments, you will usually have a local mirror URL there.

The images.yml file is just one example of how to use Image Manager. In OSISM, we use an automatically generated file for this purpose that utilizes the last-X URL (https://github.com/osism/python-osism/blob/main/osism/data/__init__.py#L37-L69), and in other environments, we do this via K-ORC.

[mbuechse]

Thanks! The new URL has found its way into v2 already; maybe we should amend v1 as well...

Naturally, CSPs can and should use their local mirror, but the image_source field is not supposed to contain the local mirror, but a widely accepted trusted reference.

[mbuechse]

@berendt It seems like the CAPI image on regio-a still uses the old image source. Are these images outdated over there, or is the source just wrong?

[berendt]

@berendt It seems like the CAPI image on regio-a still uses the old image source. Are these images outdated over there, or is the source just wrong?

The images are from previous tests. We don't use CAPI there ourselves. They are outdated and could be deleted.