tibeer
commented
1 year ago Just my two cents:
- Agreed
- No opinion
- Agreed
- Agreed (As nobody prevents CSP's to create their own, additional flavor names, I see no problem with the SCS prefix)
- Agreed
- Agreed
- Agreed (As nobody prevents CSP's to create their own, additional flavor names, I see no problem with the SCS prefix)
- Agreed
- No opinion (Though I might trow in that this enforces SCS providers, especially if this runs in-house, to provide some sort of local storage/hyperconverged nodes. Might be undesireable if you pay for a huge netapp cluster already and you don't have the requirement to run k8s clusters; but as already said: I have no opinion on that topic due to lack of information)
- Agreed
- Agreed
- Agreed
Thanks a lot for coming up with those suggestions!
PSwatchmen
garloff
The SCS community had agreed on a standard flavor naming scheme and standard flavors back in 2021. The discussion was somewhat lengthy. In the process a document explaining the logic and a v1 flavor naming specification were agreed upon. This was considered to be a mandatory SCS standard on the IaaS layer since then. The software engineering rule that something that is not tested is (almost) always broken also hit us here: In summer 2022, we observed SCS cloud providers not implementing the standard fully correctly. Since then a checker tool has been created that can validate a flavor or generate a flavor name from parameters. A tool to check all flavors has been added and it is called from the compliance check test suite whose results are displayed on github. Our CSP partners were successful in becoming fully compliant in fall 2022.
Unfortunately, the original v1 proposal contains
:in their names and certain k8s tools (OpenShift) use the infra flavor names as labels in Kubernetes, where:is not allowed. This causes trouble running OpenShift on top of SCS IaaS with v1 flavor names. A v2 scheme was discussed and created.Unfortunately, the migration causes some pain for providers. In the Nuremberg Hackathon, we found out that not all SCS IaaS providers have a clear commitment to implement the v2 flavors and work with us to minimize the pain. This would be unfortunate, stripping SCS from one of the benefits where flavor related pain points for migrations and/or simultaneous multi-cloud deployments are addressed.
Currently, the SCS compliance specification allows for both v1 and v2 compliance and the clouds are checked for both. However, this is currently scheduled to end on October 2023. The SCS project leader wants to have an agreed strategy long before October comes and has thus written a discussion document: Why do we need to standardize flavors and flavor names.
The document breaks down the discussion into 12 suggestions. Some of them might not be controversial at all, some may be. The author would like to invite everyone to comment on the suggestions. He would also like to suggest that anyone expressing his/her agreement or disagreement or extra consideration does relate it to a specific suggestion (or set of suggestions). For this, issues on each suggestion have been created, so the discussion does not get confusing. Of course the author might have overlooked important aspects for this discussion, so it is possible that discussion topics beyond the 12 suggestions pop up. Additional issues might be opened up and linked here then. Global discussion (comments affecting many of the suggestions at once) can happen here, would still be good to be precise on what aspect is being commented on.