-
Notifications
You must be signed in to change notification settings - Fork 24
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
Alternative proposal for a volume type standard #453
Conversation
680ef59
to
3398cb9
Compare
Signed-off-by: Matthias Büchse <[email protected]>
Signed-off-by: Matthias Büchse <[email protected]>
3398cb9
to
d5034b2
Compare
As an SCS user, I want to be able to create volumes with certain common features, such as encryption or | ||
replication, and to do so in a standardized manner as well as programmatically. | ||
This standard outlines a way of formally advertising these common features for a volume type to | ||
non-privileged users, so that the most suitable volume type can be discovered and selected easily--both by |
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.
Missing white spaces?
non-privileged users, so that the most suitable volume type can be discovered and selected easily--both by | |
non-privileged users, so that the most suitable volume type can be discovered and selected easily -- both by |
The features of a volume type MAY be advertised by putting a _feature list_ in front of its description. | ||
A feature list has the following form: | ||
|
||
`[feat:`feat1,feat2,...,featN`]` |
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.
To separate from other approaches, I prefer an scs specific prefix, such as scs-feat
.
## Recommended volume types | ||
|
||
At least one volume type SHOULD feature encryption. | ||
|
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 prefer to add an example, as in previous approach #351:
openstack volume type show LUKS
+--------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field | Value |
+--------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+
| access_project_ids | None |
| description | [scs:encrypted] This volume uses LUKS-encryption |
| id | d63307fb-167a-4aa0-9066-66595ea9fb21 |
| is_public | True |
| name | LUKS |
| qos_specs_id | None |
+--------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
||
where the entries (feat1, ..., featN) are sorted alphabetically, and each entry occurs at most once. | ||
|
||
## Recommended volume types |
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.
Should we specify mandartory or recommenced properties of encryption, such as cipher and key size?
|
||
At least one volume type SHOULD feature encryption. | ||
|
||
At least one volume type SHOULD feature replicaton. |
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 prefer to add define requirements or recommendations for replication. I.e. how replication ins achieved and how many replicas exists.
At least one volume type SHOULD feature encryption. | ||
|
||
At least one volume type SHOULD feature replicaton. | ||
|
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 suggest to add an example, like in #351
+--------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field | Value |
+--------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+
| access_project_ids | None |
| description | [scs:encrypted][scs:replicated] Content will be replicated three times to ensure consistency and availability for your data. LUKS encryption is used. |
| id | d63307fb-167a-4aa0-9066-66595ea9fb21 |
| is_public | True |
| name | hdd-three-replicas-LUKS |
| properties | |
| qos_specs_id | None |
+--------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+
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.
Standard reviewed and actions required.
I was wondering: Since @anjastrunk now reviewed this PR, and #351 is still open and thus far there was no further discussion (as far as I know (and nothing in the minutes of Sig Std) I wondered wether this has been discussed between @josephineSei, @mbuechse and @anjastrunk as I suggested. |
Co-authored-by: Matthias Büchse <[email protected]> Signed-off-by: anjastrunk <[email protected]>
can this PR be closed since the other volume type standards PR got basically finalized? |
this has been dealt with in #351 |
resolves #265
This is meant to illustrate what I have in mind. I did not include the optional features, but I think it's easy to see how they would fit in.