Define minimum requirement of IaaS APIs

[josephineSei]

In SovereignCloudStack/issues#528 we define sets of mandatory and supported APIs.
This is a lengthy discussion.

But we may not only define, what APIs we expect to see in a cloud but also how old they are allowed to be.
On the KaaS Layer there is already a standard: https://github.com/SovereignCloudStack/standards/blob/main/Standards/scs-0210-v1-k8s-new-version-policy.md , which advises to closely follow the K8s releases.

We need to also define a period of Liveness for the IaaS Layer.

Definition of Done:

Please refer to scs-0001-v1 for details.

• Proposal has been written with name of the form scs-xxxx-v1-slug.md (only substitute slug)
• Proposal has the fields status, type, track set
• Proposal has been voted upon in the corresponding team
• Status has been changed into Draft, file renamed: xxxx replaced by document number
• If applicable: test script has been written (this item may be moved into a separate issue so long as the state is Draft)

[josephineSei]

The question here is: How can we determine, which version of the IaaS-API is used? And how many version we want to support on IaaS-Level.

1. One Option would be to allow all IaaS APIs, that are still maintained (e.g. OpenStack services, that are still maintained and not in EOL or Unmaintained: https://releases.openstack.org/).
2. Another Option would be to also allow Unmaintained release, when CSPs will A) fix all security issues themself and B) maybe have an upgrade plan to finally rely on maintained IaaS services.

Testing this will be quite tricky.

We could use the openstack version show:

stack@devstack:~/devstack$ openstack versions show
+-------------+----------------+---------+-----------+---------------------------------------------+------------------+------------------+
| Region Name | Service Type   | Version | Status    | Endpoint                                    | Min Microversion | Max Microversion |
+-------------+----------------+---------+-----------+---------------------------------------------+------------------+------------------+
| RegionOne   | placement      | 1.0     | CURRENT   | http://192.168.23.161/placement/            | 1.0              | 1.39             |
| RegionOne   | compute        | 2.0     | SUPPORTED | http://192.168.23.161/compute/v2/           | None             | None             |
| RegionOne   | compute        | 2.1     | CURRENT   | http://192.168.23.161/compute/v2.1/         | 2.1              | 2.96             |
| RegionOne   | block-storage  | 3.0     | CURRENT   | http://192.168.23.161/volume/v3/            | 3.0              | 3.71             |
| RegionOne   | image          | 2.0     | SUPPORTED | http://192.168.23.161/image/v2/             | None             | None             |
| RegionOne   | image          | 2.1     | SUPPORTED | http://192.168.23.161/image/v2/             | None             | None             |
| RegionOne   | image          | 2.2     | SUPPORTED | http://192.168.23.161/image/v2/             | None             | None             |
| RegionOne   | image          | 2.3     | SUPPORTED | http://192.168.23.161/image/v2/             | None             | None             |
| RegionOne   | image          | 2.4     | SUPPORTED | http://192.168.23.161/image/v2/             | None             | None             |
| RegionOne   | image          | 2.5     | SUPPORTED | http://192.168.23.161/image/v2/             | None             | None             |
| RegionOne   | image          | 2.6     | SUPPORTED | http://192.168.23.161/image/v2/             | None             | None             |
| RegionOne   | image          | 2.7     | SUPPORTED | http://192.168.23.161/image/v2/             | None             | None             |
| RegionOne   | image          | 2.9     | SUPPORTED | http://192.168.23.161/image/v2/             | None             | None             |
| RegionOne   | image          | 2.14    | SUPPORTED | http://192.168.23.161/image/v2/             | None             | None             |
| RegionOne   | image          | 2.15    | SUPPORTED | http://192.168.23.161/image/v2/             | None             | None             |
| RegionOne   | image          | 2.16    | CURRENT   | http://192.168.23.161/image/v2/             | None             | None             |
| RegionOne   | compute_legacy | 2.0     | SUPPORTED | http://192.168.23.161/compute/v2/           | None             | None             |
| RegionOne   | compute_legacy | 2.1     | CURRENT   | http://192.168.23.161/compute/v2.1/         | 2.1              | 2.96             |
| RegionOne   | key-manager    | 1.0     | CURRENT   | http://192.168.23.161/key-manager/v1/       | None             | None             |
| RegionOne   | identity       | 3.14    | CURRENT   | http://192.168.23.161/identity/v3/          | None             | None             |
| RegionOne   | network        | 2.0     | CURRENT   | http://192.168.23.161:9696/networking/v2.0/ | None             | None             |
+-------------+----------------+---------+-----------+---------------------------------------------+------------------+------------------+

But within there we only have the microversions, which not all projects have and which may not be updated in certain releases. (+ the key-manager uses microversions, but it is not shown here!)
That means we can only sporadically test certain API endpoints - and for non-OpenStack use cases, the micro-versions might even differ.

Another Option would be to specifically test for certain endpoints to be present (e.g. openstack default security group rule list) . This would include non-OpenStack services, but is so specific, that we may have to update this test every release cycle.