Skip to content
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

Create standard for mandatory and supported IaaS services #587

Merged
merged 32 commits into from
Nov 13, 2024
Merged
Show file tree
Hide file tree
Changes from 13 commits
Commits
Show all changes
32 commits
Select commit Hold shift + click to select a range
5d94f74
Create scs-XXXX-vN-mandatory-and-supported-IaaS-services.md
josephineSei May 7, 2024
7d8a514
Apply suggestions from code review
josephineSei May 17, 2024
bd52305
Update scs-XXXX-vN-mandatory-and-supported-IaaS-services.md
josephineSei May 17, 2024
1c3a6ad
Create test to check for mandatory services
josephineSei May 17, 2024
99a2434
Update mandatory-iaas-services.py
josephineSei May 17, 2024
7ed642f
Apply suggestions from code review
josephineSei May 28, 2024
1abf35b
Update scs-XXXX-vN-mandatory-and-supported-IaaS-services.md
josephineSei Jun 6, 2024
2008cab
Update mandatory-iaas-services.py
josephineSei Jun 6, 2024
d2e0a6f
Update scs-XXXX-vN-mandatory-and-supported-IaaS-services.md
josephineSei Jun 17, 2024
9b97d9a
Apply suggestions from code review
josephineSei Jun 18, 2024
8d5200c
Update scs-XXXX-vN-mandatory-and-supported-IaaS-services.md
josephineSei Jun 19, 2024
3b00013
Apply suggestions from code review
josephineSei Jul 1, 2024
bbbf13f
Re-arranging APIs to alphabetical order
josephineSei Jul 1, 2024
9ca339c
Name a specific standard (role standard) that requires knowledge abou…
josephineSei Aug 15, 2024
d10574c
Merge branch 'main' into mandatory-and-supported-IaaS-services
josephineSei Aug 15, 2024
7858db1
Update scs-XXXX-vN-mandatory-and-supported-IaaS-services.md
josephineSei Aug 30, 2024
a07b718
Update mandatory-iaas-services.py
josephineSei Aug 30, 2024
aebc1c2
Update mandatory-iaas-services.py
josephineSei Sep 24, 2024
12b88a9
Update scs-XXXX-vN-mandatory-and-supported-IaaS-services.md
josephineSei Sep 24, 2024
2795cbb
Update mandatory-iaas-services.py
josephineSei Sep 24, 2024
78d6852
Merge branch 'main' into mandatory-and-supported-IaaS-services
josephineSei Sep 24, 2024
673f0e5
Update mandatory-iaas-services.py
josephineSei Sep 24, 2024
2077e5f
Merge branch 'main' into mandatory-and-supported-IaaS-services
josephineSei Sep 25, 2024
9e4fb38
Update mandatory-iaas-services.py
josephineSei Sep 26, 2024
c1c4009
Update mandatory-iaas-services.py
josephineSei Sep 30, 2024
68e147b
Merge branch 'main' into mandatory-and-supported-IaaS-services
josephineSei Sep 30, 2024
30a5eb0
Create README.md
josephineSei Sep 30, 2024
7271122
Merge branch 'main' into mandatory-and-supported-IaaS-services
josephineSei Oct 4, 2024
c2a1b8b
change aki to ak and sak to sk
josephineSei Nov 8, 2024
51ac434
Merge branch 'main' into mandatory-and-supported-IaaS-services
josephineSei Nov 8, 2024
8fe2f13
Merge branch 'main' into mandatory-and-supported-IaaS-services
josephineSei Nov 13, 2024
68df301
Rename scs-XXXX-vN-mandatory-and-supported-IaaS-services.md to scs-01…
josephineSei Nov 13, 2024
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
77 changes: 77 additions & 0 deletions Standards/scs-XXXX-vN-mandatory-and-supported-IaaS-services.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,77 @@
---
title: Mandatory and Supported IaaS Services
type: Standard
status: Draft
track: IaaS
---

## Introduction

To be SCS-compliant a Cloud Service Provider (CSP) has to fulfill all SCS standards.
Some of those standards are broad and consider all APIs of all services on the IaaS-Layer.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please be specific and name at least one example?

There exist many services on that layer and for a first step they need to be limited to have a clear scope for the standards and the Cloud Service Providers following them.
For this purpose, this standard will establish lists for mandatory services whose APIs have to be present in a SCS cloud as well as supported services, which APIs are considered by some standards and may even be tested for their integration but are optional in a sense that their omission will not violate SCS conformance.

## Motivation

There are many OpenStack APIs and their corresponding services that can be deployed on the IaaS level.
These services have differences in the quality of their implementation and liveness and some of them may be easily omitted when creating an IaaS deployment.
To fulfill all SCS-provided standards only a subset of these APIs are required.
Some more but not all remaining OpenStack APIs are also supported additionally by the SCS project and may be part of its reference implementation.
josephineSei marked this conversation as resolved.
Show resolved Hide resolved
This results in different levels of support for specific services.
This document will give readers insight about how the SCS classifies the OpenStack APIs accordingly.
If a cloud provides all mandatory and any number of supported OpenStack APIs, it can be tested for SCS-compliance.
Any unsupported APIs will not be tested.

## Mandatory IaaS APIs

The following IaaS APIs MUST be present in SCS-compliant IaaS deployments and could be implemented with the corresponding OpenStack services:

| Mandatory API | corresponding OpenStack Service | description |
|-----|-----|-----|
| **block-storage** | Cinder | Block Storage service |
| **compute** | Nova | Compute service |
| **identity** | Keystone | Identity service |
| **image** | Glance | Image service |
| **load-balancer** | Octavia | Load-balancer service |
| **network** | Neutron | Networking service |
| **s3** or **object-store** | S3 API object storage | No formal standard exists, many implementations: Swift, RadosGW, minio... |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I personally dislike "or" here. There are user loads supporting only one of both so having here an OR does not bring much benefit. S3 support in it's own is not standardized enough to have multiple compatibility issues, especially when it comes to the OpenStack Identity related stuff.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see your point. It was a requirement from the beginning to have an object store API as mandatory in each scs-cloud.
CSPs right now use different kinds of object-stores. So we have two options: either make one specific implementation mandatory or we state that CSPs can and must choose an implementation and users have to live with these different options.

Another option would be to make this optionally, but we would have to discuss this again with the IaaS team and Kurt.

What is your opinion on this?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We discussed this in the standardization SIG and following items were raised:

  • S3 was always intended to be mandatory (also for KaaS layer)
  • Swift should be at least "recommended"
    Even though S3 and Swift both implement the same service (object-store) it can be seen as: HDMI output is a must and DisplayPort is recommended

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And it should be two separate rows

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will change the standard accordingly.
BUT, if S3 is also listed as "object-store" equal to Swift, we have no chance to distinguish between those two services in the tests.
This is a little bit unfortunate, because we will never know for certain, whether the endpoints are from an S3 service or from Swift. So I can change the lines here, but we will not be able to test them!

An option may be to use gaia-x credentials. Which raises the question: Do we have a point, were we state which credentials we require? @garloff ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO, in this context, we need a standard for object storage too, similar like for block storage. CSPs need to know the requirements for object store and users need to know, which capabilities an object store has. See, #725

Copy link
Contributor

@anjastrunk anjastrunk Sep 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree to @josephineSei: We can not distinguish between two object store APIs in tests. We should define just one as mandatory. Furthermore, setting S3 as mandatory is problematic. As far as I known, S3 API is not in control of OpenStack. There is no official documentation on how S3 for a specific OpenStack release looks like. The latest documentation is from Mitaka. There is no documentation for current release, e.g. Hence, we standardize a moving target IMO.

Copy link
Contributor

@anjastrunk anjastrunk Oct 14, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is still an open question with respect to version of a certain OpenStack service. E.g. how does a consumer knows, which version of Nova is provided by a CSP? We will answer this question in #765


:::caution

S3 API implementations may differ in certain offered features.
CSPs must publicly describe, which implementation they use in their deployment.
artificial-intelligence marked this conversation as resolved.
Show resolved Hide resolved
Users should always research whether a needed feature is supported in the offered implementation.

:::

## Supported IaaS APIs

The following IaaS APIs MAY be present in SCS-compliant IaaS deployment, e.g. implemented thorugh the corresponding OpenStack services, and are considered in the SCS standards.
josephineSei marked this conversation as resolved.
Show resolved Hide resolved

| Supported API | corresponding OpenStack Service | description |
|-----|-----|-----|
| **bare-metal** | Ironic | Bare Metal provisioning service |
| **billing** | Cloudkitty | Rating/Billing service |
| **dns** | Designate | DNS service |
| **ha** | Masakari | Instances High Availability service |
| **key-manager** | Barbican | Key Manager service |
| **orchestration** | Heat | Orchestration service |
| **shared-file-systems** | Manila | Shared File Systems service |
| **telemetry** | Ceilometer | Telemetry service |
| **time-series-databse** | Gnocchi | Time Series Database service |

## Unsupported IaaS APIs

All other OpenStack services, whose APIs are not mentioned in the mandatory or supported lists will not be tested for their compatibility and conformance in SCS clouds by the SCS community.
Those services MAY be integrated into IaaS deployments by a Cloud Service Provider on their own responsibility but the SCS will not assume they are present and potential issues that occur during deployment or usage have to be handled by the CSP on their own accord.
The SCS standard offers no guarantees for compatibility or reliability of services categorized as unsupported.

## Related Documents

[The OpenStack Services](https://www.openstack.org/software/)

## Conformance Tests

The presence of the mandatory OpenStack APIs (except the S3) will be tested in a test-script.
As the S3 interface is a moving target, it may be integrated into the test suite but the test result will not be taken into account to determine conformance.
96 changes: 96 additions & 0 deletions Tests/iaas/mandatory-services/mandatory-iaas-services.py
Original file line number Diff line number Diff line change
@@ -0,0 +1,96 @@
"""Mandatory APIs checker

This script retrieves the endpoint catalog from Keystone using the OpenStack
SDK and checks whether all mandatory APi endpoints, are present.
The script relies on an OpenStack SDK compatible clouds.yaml file for
authentication with Keystone.
As the s3 endpoint might differ, a missing one will only result in a warning.
"""

import argparse
import logging
import os

import openstack


logger = logging.getLogger(__name__)
mandatory_services = ["compute", "identity", "image", "block-storage",
"network", "load-balancer", "placement"]
object_store_service = ["s3", "object-store"]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have never seen a single cloud having S3 service/endpoint in the catalog. Typically object-store is also supporting S3 (either it is swift with S3 enabled or it is rgw catalog pointing to swift endpoint).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can remove it, if there really is no cloud with "s3" as service type. But can we certainly know, that this will never be the case?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no tooling existing in the world (known to me) that expects S3 and consumes OpenStack service catalog searching for "s3" service type



def connect(cloud_name: str) -> openstack.connection.Connection:
"""Create a connection to an OpenStack cloud
:param string cloud_name:
The name of the configuration to load from clouds.yaml.
:returns: openstack.connnection.Connection
"""
return openstack.connect(
cloud=cloud_name,
)


def check_presence_of_mandatory_services(cloud_name: str):
try:
connection = connect(cloud_name)
services = connection.service_catalog
except Exception as e:
print(str(e))
raise Exception(
f"Connection to cloud '{cloud_name}' was not successfully. "
f"The Catalog endpoint could not be accessed. "
f"Please check your cloud connection and authorization."
)

for svc in services:
svc_type = svc['type']
if svc_type in mandatory_services:
mandatory_services.remove(svc_type)
continue
if svc_type in object_store_service:
object_store_service.remove(svc_type)

if len(object_store_service) == 2:
# neither s3 nor object-store is available,
# but might be named differently
logger.warning("No s3 or object-store endpoint found.")
if not mandatory_services:
# every mandatory service API had an endpoint
return 0
else:
# there were multiple mandatory APIs not found
logger.error(f"The following endpoints are missing: "
f"{mandatory_services}")
return len(mandatory_services)


def main():
parser = argparse.ArgumentParser(
description="SCS Mandatory IaaS Service Checker")
parser.add_argument(
"--os-cloud", type=str,
help="Name of the cloud from clouds.yaml, alternative "
"to the OS_CLOUD environment variable"
)
parser.add_argument(
"--debug", action="store_true",
help="Enable OpenStack SDK debug logging"
)
args = parser.parse_args()
openstack.enable_logging(debug=args.debug)

# parse cloud name for lookup in clouds.yaml
cloud = os.environ.get("OS_CLOUD", None)
if args.os_cloud:
cloud = args.os_cloud
assert cloud, (
"You need to have the OS_CLOUD environment variable set to your cloud "
"name or pass it via --os-cloud"
)

return check_presence_of_mandatory_services(cloud)


if __name__ == "__main__":
main()