Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Create standard for mandatory and supported IaaS services #587
Changes from 15 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
There are no files selected for viewing
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.
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 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?
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.
We discussed this in the standardization SIG and following items were raised:
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
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.
And it should be two separate rows
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.
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 ?
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.
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 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.
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.
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
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.
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).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.
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 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