-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SCS Standard Images reference YAML not clearly communicated #534
Comments
This is not controversial – I agree on all accounts. Thanks for spotting this. |
For context: When we crafted this standard, the docs page wasn't as advanced nor as widely adopted as today. So it should be updated without question. |
On second thought, the crux here is the following: from my point of view, this standard merely regulates the format of the YAML file; which YAML file is ultimately used is not part of the standard, but a parameter of the certificate subject. Well, apparently, this doesn't seem to be the most practical point of view... So this turns out to be something we should discuss in the SIG after all(!) |
Let me expand on my previous statement. Currently, what YAML is relevant is solely determined in the certificate scope: - name: Standard images
url: https://raw.githubusercontent.com/SovereignCloudStack/standards/main/Standards/scs-0104-v1-standard-images.md
checks:
- executable: ./iaas/standard-images/images-openstack.py
args: -c {os_cloud} -d ./iaas/scs-0104-v1-images.yaml
id: standard-images-check Arguably, this is too arcane and not appropriate. We could introduce explicit parameters (that could then be listed in the docs, albeit in the docs for the certificate scope) like so: - name: Standard images
url: https://raw.githubusercontent.com/SovereignCloudStack/standards/main/Standards/scs-0104-v1-standard-images.md
parameters:
images_yaml: https://raw.githubusercontent.com/SovereignCloudStack/standards/main/Tests/iaas/scs-0104-v1-images.yaml
checks:
- executable: ./iaas/standard-images/images-openstack.py
args: -c {os_cloud} -d {images_yaml}
id: standard-images-check In this case, we would need to debate the type of the parameter -- if we want it clickable in the docs, a URL like in this example would be good, but I would also want to avoid the additional roundtrip for the download in the test script (so maybe include a special case for URLs that point to the same repo). Another point of debate would be the presentation in the docs -- currently we have this table:
The parameters would go in here somewhere, but obviously we would need more space for them. |
From reading the standard I first assumed, it will state the required images. I agree with @markus-hentsch that we need to have a better way to present the yaml files (if they contain the images for the recent conformance tests / label). For example to pointing to the currently effective certificate scopes. This would also allow CSPs to check which yaml is needed for their scope and what to do to be able to "upgrade" to the next scope. |
Related to #534 (but not quite resolving it). Signed-off-by: Matthias Büchse <matthias.buechse@cloudandheat.com>
(bold emphasis added by me) Currently, the source file classifies it as type "Standard"1 whereas from my point of view, the majority of the content leans more towards the "Procedural" type as it explains a process rather than a standard that a CSP is to implement. But maybe I'm misinterpreting this classification. Seems like there is no easy/obvious way how to go forward with this. I'll put it on the agenda for the next possible IaaS call2 for now. Footnotes
|
This issue should be mitigated by formal parameters. Nevertheless, we should also change this into a Procedural and add implementation notes. |
Signed-off-by: Matthias Büchse <matthias.buechse@cloudandheat.com>
Signed-off-by: Matthias Büchse <matthias.buechse@cloudandheat.com>
Signed-off-by: Matthias Büchse <matthias.buechse@cloudandheat.com>
Putting myself into the perspective of a CSP that aims for SCS conformance I noticed the following shortcomings while reading the "SCS Standard Images" document in the official SCS docs at https://docs.scs.community/standards/scs-0104-v1-standard-images and trying to reach conformance to it.
Current shortcomings
The standard spends a lot of time elaborating on the process of how images are standardized and how the standardization is implemented using YAML descriptions but little on how to figure out the currently standardized images.
My primary question as a CSP would be: "What images do I have to provide to be SCS compliant?". I don't feel this question is answered in a confident way. The standard currently only states this small sentence under the headlines "Lifecycle considerations"/"YAML lifecycle":
Problems with that:
Suggestions for improvement
In general, I would like to improve the discoverability of the images YAML file2 and emphasize its role in relation to achieving standard conformance, just like in other standards (e.g. the flavor standard where mandatory and recommended flavors are listed directly in the standard):
I'd like to hear your opinion on this.
Footnotes
https://github.com/osism/openstack-image-manager/tree/main/etc/images ↩
https://github.com/SovereignCloudStack/standards/blob/main/Tests/iaas/scs-0104-v1-images.yaml ↩ ↩2
The text was updated successfully, but these errors were encountered: