Extend implementation notes

[cah-hbaum]

Add and extend some implementation notes derived from the findings of #426.

[cah-hbaum]

Not sure if the link checker is good in this state or how links should be entered.
I wrote in some links to a file that will be create WITH this PR. I already wrote in the main branch, since it WILL be there soon, but it isn't yet, so this gets marked as a dead link...

Which would be the correct workflow here? (maybe @martinmo, I think he worked on this)

[mbuechse]

Thanks for the good work! The supplements should be a bit more succinct; they are not stand-alone documents, and they shouldn't duplicate content from the main document. They should, however, be actionable, and I think this has been achieved. Unfortunately, for one of the documents, there is a conflict with another pending (albeit approved) PR, and I have some reservations about the new spec file.

[mbuechse]

This seems to incur quite some maintenance work whenever we change the set of standard images. To me, it would be preferable to guide people to the specs provided by OSISM and tell them to use those parts that they deem relevant, including (of course) those that are mandatory from the POV of SCS. Maybe we can work with OSISM to make this process automatic; then we should open an issue about that.

[cah-hbaum]

I understand where you come from, but we already provide a set of standard images in the form https://github.com/SovereignCloudStack/standards/blob/main/Tests/iaas/scs-0104-v1-images.yaml.
So IMO, its not that much of a deal to also provide this other file, since its practically is derived from the first one.
And we also don't say that this is the only solution, but its quite a good guidance.

[mbuechse]

The set of standard images you're referring to is merely fixing the image source, so people know what to expect when they encounter a certain name. The spec file, on the other hand, contains quite a lot of specific details that I (as a standards person) have absolutely no expertise about. So I'm not convinced.

[martinmo]

I agree with Hannes here: to make it easier for a CSP to become compliant, it would be really nice to have a complete, working YAML that can just be fed to the openstack-image-manager. At the moment, you'll need to assemble parts of it yourself (I exercised this recently):

• go to https://github.com/osism/openstack-image-manager/tree/main/etc/images
• find and copy ubuntu and debian files
• filter unnecessary things from the ubuntu files (e.g., versions 18.04 and older, "Minimal" variants)
• for the CAPI images, it is even more difficult, because the kubernetes.yml in that directory is not up-to-date
  • in the OSISM stack, the osism cli tool is used for this purpose (osism manage image clusterapi as mentioned here)
  • it creates an up-to-date YAML on the fly and feeds it to the image manager (https://github.com/osism/python-osism/blob/main/osism/commands/manage.py)

However, I disagree with the file name choice: it should reflect that it is meant for v1 of scs-0104 and to be fed to the image manager.

[mbuechse]

Yes, people will have to do this. However, we can't keep this file up to date, which is what OSISM (semi-) automatically does in their repo. That we used the versions wrong is just the evidence that we shouldn't meddle in this.

[cah-hbaum]

Most things should be adressed with 804b5c3

[martinmo]

Because Hannes is blocked, I'll adopt this PR (I need it for SovereignCloudStack/docs#212)

[artificial-intelligence]

LGTM as far as I can see on mobile