Add Standards/scs-0104-v2-standard-images.md #989
Conversation
|
Should the image_source format always be from the osism repository or should we not be able to host our own images? |
This is up for debate. So far, this hasn't come up. If other people want to host the image, they can probably be added, given that the relevant bodies agree. |
garloff
left a comment
garloff
left a comment
There was a problem hiding this comment.
Another comment:
We've had standardized image names before. Shouldn't we keep them as a recommendation? This would reduce the chance for breakage of customer automation ...
|
|
||
| ### Official SCS CAPI images | ||
|
|
||
| | status | name scheme | |
There was a problem hiding this comment.
Shouldn't we specify os_distro and os_purpose in this table as well?
There was a problem hiding this comment.
Hm. I think these images are to be found via name, because os_distro and os_purpose are not specific enough, or are they?
There was a problem hiding this comment.
But they still should be set correctly
There was a problem hiding this comment.
Agreed, but this should be mandated by scs-0101 already. The same is true for the plain OS images, though. I will work on it.
There was a problem hiding this comment.
On second thought, the thing is this:
- in the first table, we say "an image with this combination of properties MUST/SHOULD exist"
- in the second table, we say "an image with this name SHOULD exist"
- scs-0101-v2 mandates the correct use of
os_purposeandos_distro; we don't do that here
Therefore, IMO we shouldn't specify the property values here.
mbuechse
force-pushed
the
feat/scs-0104-v2
branch
from
de63eb2 to
2991d81
Compare
Signed-off-by: Matthias Büchse <matthias.buechse@alasca.cloud>
Signed-off-by: Matthias Büchse <matthias.buechse@alasca.cloud>
mbuechse
force-pushed
the
feat/scs-0104-v2
branch
from
2991d81 to
f0b72ff
Compare
Signed-off-by: Matthias Büchse <matthias.buechse@alasca.cloud>
|
|
||
| the value of the property `image_source` MUST have the form | ||
|
|
||
| https://swift.services.a.regiocloud.tech/swift/v1/AUTH_b182637428444b9aa302bb8d5a5a418c/openstack-k8s-capi-images/... |
There was a problem hiding this comment.
| https://swift.services.a.regiocloud.tech/swift/v1/AUTH_b182637428444b9aa302bb8d5a5a418c/openstack-k8s-capi-images/... | |
| https://nbg1.your-objectstorage.com/osism/openstack-k8s-capi-images/... |
See https://github.com/osism/k8s-capi-images (which should be in image_description).
There was a problem hiding this comment.
We could also mention that the os_purpose for these MUST be set to k8snode and that image_description be set to https://github.com/osism/k8s-capi-images.
Provider are free to register capi images with a different naming scheme from different source.
There was a problem hiding this comment.
I like that. It's more fitting here than in the section below. I will implement this.
Shall we allow the old URL to remain backwards compatible?
There was a problem hiding this comment.
I changed the text accordingly --- with the old URL for backwards compatibility. @garloff please have another look.
|
|
||
| ### Generic OS images | ||
|
|
||
| For an OS image with `os_purpose=generic`, the `image_source` SHOULD come from the original vendor. |
There was a problem hiding this comment.
| For an OS image with `os_purpose=generic`, the `image_source` SHOULD come from the original vendor. | |
| For an OS image with `os_purpose=generic`, the `image_source` SHOULD come from the original vendor. This allows the user to download and inspect the image - the registered image thus MUST NOT be changed from the one that can be downloaded from the `image_source` URL. |
There was a problem hiding this comment.
I like this, but I'm pretty positive it belongs into scs-0102 (image metadata).
Co-authored-by: Kurt Garloff <kurt@garloff.de> Signed-off-by: Matthias Büchse <matthias.buechse@alasca.cloud>
Closes #933