Decision Record: keep capi images recommended #582
Conversation
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.
mxmxchere
added
IaaS
Standards/scs-0115-v0-capi-images.md
Outdated
| 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.
There was a problem hiding this comment.
Thanks for the summary @berendt - this is exactly what I'd have written.
From my point of view the impact for the CSP is fairly low while having a large impact for the customer whose Cluster-API stuff simply works.
There was a problem hiding this comment.
With the local storage, there was nothing a user could do if they needed the performance. The images, however, can be uploaded by the user. Yes, this does require some additional effort and it might waste some time and energy and produce emissions etc., but it is possible. So from my POV it should be up to the CSP to decide whether they want to meet their customers halfway here or not (if they do, they can advertise as much). I don't see the need to make it mandatory.
There was a problem hiding this comment.
At the moment we provide them at https://github.com/osism/k8s-capi-images. We do not test them at the moment. There is an issue open for this. We are currently depending on the feedback from the SCS K8s team for the tests. If there is no negative feedback from them, we assume that the images are working.
Building the images themselves is trivial with the https://github.com/kubernetes-sigs/image-builder/ .
There was a problem hiding this comment.
We've discussed this in today's PB again and the overall consensus was that these images should be RECOMMENDED and not MANDATORY.
This allows CSPs to follow the recommendation, without having the burden to maintain the images if they really don't want to carry them. Imho we should make sure the discussion is reflected in the decision record.
There was a problem hiding this comment.
Recommended instead of mandatory is the status quo, from my point of view we need no decision record for that.
The only thing that can be "improved" in the standards is the concatenation between the SCS K8S Version Policy 0210-v2 and the recommended issues. But as these standards are neither binding nor would an additional concatenation document add any new informational value I see no point in doing that either. In the worst case we build in a contradiction somewhere and create confusion. So from my point of view we can just close this PR (unmerged)
There was a problem hiding this comment.
@mxmxchere I suggested the decision record so that the discussion is manifested outside of this PR. ;)
There was a problem hiding this comment.
@frosty-geek At last! I updated this document to reflect our ultimate decision. I think it will be to your liking now. Please approve this PR in order to remove your change request, so that it becomes unblocked.
|
Hi everyone, I will take over for Malte on this PR. It will be rededicated a bit just to document why we decided to keep the CAPI images non-mandatory. |
thanks @mbuechse |
mbuechse
changed the title
mbuechse
force-pushed
the
require-k8s-images
branch
from
f3e5a8b
to
b01f2ef
Compare
Signed-off-by: Malte Münch <[email protected]>
Signed-off-by: Malte Münch <[email protected]>
Signed-off-by: Malte Münch <[email protected]>
Signed-off-by: Malte Münch <[email protected]>
Signed-off-by: Matthias Büchse <[email protected]>
Signed-off-by: Matthias Büchse <[email protected]>
Signed-off-by: Matthias Büchse <[email protected]>
Signed-off-by: Matthias Büchse <[email protected]>
Signed-off-by: Matthias Büchse <[email protected]>
Signed-off-by: Matthias Büchse <[email protected]>
Signed-off-by: Matthias Büchse <[email protected]>
mbuechse
force-pushed
the
require-k8s-images
branch
from
b01f2ef
to
2bc6ff9
Compare
Signed-off-by: Malte Münch [email protected]