Decision Record: capi images mandatory #582
Conversation
Signed-off-by: Malte Münch <muench@b1-systems.de>
Signed-off-by: Malte Münch <muench@b1-systems.de>
Signed-off-by: Malte Münch <muench@b1-systems.de>
Standards/scs-0115-v0-capi-images.md
Outdated
|
|
||
| From the meeting notes: | ||
|
|
||
| - will save time and money for both CSP and customer |
There was a problem hiding this comment.
It also saves physical resources & power.
Signed-off-by: Malte Münch <muench@b1-systems.de>
mxmxchere
added
IaaS
| This would lead to the following standard changes: | ||
| Create a copy of the [default image list](https://github.com/SovereignCloudStack/standards/blob/main/Tests/iaas/scs-0104-v1-images.yaml) and change the capi block from "recommended" to "mandatory". | ||
|
|
||
| Also, strictly speaking, we have to change [the standard image format definition](https://github.com/SovereignCloudStack/standards/blob/main/Standards/scs-0104-v1-standard-images.md#image-specification-class-of-images) so that "mandatory" for an image class does not mean that at least one image MUST be present in glance but all that match the [SCS K8S Version Policy](https://docs.scs.community/standards/scs-0210-v2-k8s-version-policy#motivation). Also the checking script has to be adapted. |
There was a problem hiding this comment.
So let me get this right, as a CSP -who has no interest in offering k8s services based on CAPI- I'm forced to provide not one but how every many Images that are needed only in the scope of CAPI and keep them "maintained"?
I would rather like to not mix standards and keep the separation between IaaS, KaaS + Ops "clean".
We're already looking into how to align our Gardener based k8s Setup with the KaaS Standards and thus would follow the mandatory versions and thus at this point in time we see no benefit in accepting additional "mandatory" Images.
There was a problem hiding this comment.
Thanks for the feedback. Yes, the standard, in the above form, would force a CSP to maintain k8s CAPI images, even in a timely manner.
Maybe a compromise could be that this standard is only mandatory when your are not providing a SCS-compliant k8s service (which you plan to do, so this would not affect you). However that would also connect IaaS and KaaS layers.
There was a problem hiding this comment.
The idea behind this was to prepare an SCS-standardised infrastructure as well as possible for the use of SCS cluster stacks. A customer can use the SCS cluster stacks or cluster API in general completely independently of the Kubernetes as a Service preferred and offered by the CSP. If it is specified in the standard that a CSP must provide the cluster API images, then the SCS cluster stacks could be used without additional effort (providing an image for each project, which is definitely a disadvantage if you have to do that). I think it's basically the same as with the special flavors with local storage. Their existence was necessary due to the problems with Kubernetes managed by cluster API / SCS cluster stacks.
Signed-off-by: Malte Münch muench@b1-systems.de