-
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
Create standard for mandatory and supported IaaS services #587
Changes from 13 commits
5d94f74
7d8a514
bd52305
1c3a6ad
99a2434
7ed642f
1abf35b
2008cab
d2e0a6f
9b97d9a
8d5200c
3b00013
bbbf13f
9ca339c
d10574c
7858db1
a07b718
aebc1c2
12b88a9
2795cbb
78d6852
673f0e5
2077e5f
9e4fb38
c1c4009
68e147b
30a5eb0
7271122
c2a1b8b
51ac434
8fe2f13
68df301
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
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. | ||
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... | | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. 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? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We discussed this in the standardization SIG and following items were raised:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. And it should be two separate rows There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I will change the standard accordingly. 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 ? There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. |
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"] | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 There was a problem hiding this comment. Choose a reason for hiding this commentThe 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? There was a problem hiding this comment. Choose a reason for hiding this commentThe 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() |
There was a problem hiding this comment.
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?