Define Standard for the naming of volume types

[josephineSei]

Volumes are commonly used either as a root disk for a VM or to attach to a VM for additional disk space. Plus they are persistent, even after a VM is deleted.
There are multiple storage solutions for volumes and also the performance and whether they are encrypted or not can vary. These differences and a few other things are defined in the volume type. However, there is always a default volume type which will be used and can vary. And there is no API endpoint in OpenStack so far, that can show you all defined properties of a volume type. Uses right now can only look at the names of the types and have to decide only with this in mind, which type they choose for their volumes.

Therefore we want to define a standard for the naming of volume types. The names should include performance aspects and optional encryption type and maybe other properties.

• Find consensus about the properties, which should be stated in the volume type name
• Write Standard for the naming of volume types

[garloff]

I guess next to performance (bandwidth, latency) and encryption, users want to have an indication of redundancy/availability. In terms of "survives a disk crash, survives a node crash, survives a rack going down, survives an AZ going down" or so. (Maybe it's just two classes: Survives single disk/node failure and survives AZ failure.)
Speaking of AZs: An indication whether the volume is local to an AZ or available in all AZs of the region is also an important distinction that should be discoverable. (Not necessarily in the name.)

[josephineSei]

I put all of my gathering of information of the last days in this etherpad: https://input.scs.community/JnaY5i70R_yc7JkSNVtlKQ

I came across quite a few questions and would like to discuss them in a meeting.

[fkr]

@josephineSei thanks for the write up. I've added it to next weeks IaaS call's agenda (https://input.scs.community/2023-scs-team-iaas?view#Define-Standard-for-the-naming-of-volume-types) - are you going to be there for the call?

Upcoming week is Sprint Review & Planning, however I'll make sure we have a timebox of 10 Minutes for the topic - if needed we can breakout from there.

[josephineSei]

@fkr i will attend the next meeting

[artificial-intelligence]

when/how will the breakout session happen?

[josephineSei]

I would like to have a breakout session this week.

@artificial-intelligence , @ppkuschy , @frosty-geek , @jnull , @berendtcon , @fkr : Which of the following slots could you attend?

Wednesday: 9:05 - 10:00 or 11:05 - 12:00
Thursday: 9:00 - 10:00 or 10:00 - 11:00
Friday: 9:00 - 10:00 or 10:00 - 11:00

[artificial-intelligence]

all suggested timeslots are fine for me 👍

[jnull]

Hey there,the time slots on Thursday and Friday between 9 - 10 would be fine for me.Best wishesJeffAm 03.07.2023 um 14:49 schrieb josephineSei ***@***.***>: I would like to have a breakout session this week. @artificial-intelligence , @ppkuschy , @frosty-geek , @jnull , @berendtcon , @fkr : Which of the following slots could you attend? Wednesday: 9:05 - 10:00 or 11:05 - 12:00 Thursday: 9:00 - 10:00 or 10:00 - 11:00 Friday: 9:00 - 10:00 or 10:00 - 11:00 —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[frosty-geek]

Wednesday: 9:05 - 10:00 or 11:05 - 12:00
Thursday: 9:00 - 10:00 or 10:00 - 11:00
Friday: 9:00 - 10:00 or 10:00 - 11:00

All of the above should be doable

[fkr]

I'd prefer Wednesday 11:05 - 12:00 or Thursday 09:00 - 10:00.

[josephineSei]

So Thursday 9:00 - 10:00 it is. @fkr will open up the room for us.

[fkr]

SovereignCloudStack/calendar#181

[josephineSei]

The Conclusion from out discussion about the different aspects of Volume Types:

Aspect	Standardize?	Discoverability	other Things
encryption	Recommended	work needed	extra_spec: encrypted=True/False
Backend name	-	-	-
AZs	-	-	describe as optional and backend-dependend
multiattach	-	yes	describe as optional
Replication	Recommended	lot of work	either get from backend to OS or as extra_spec defined by deployer
Number of Replicas, etc	?	lot of work	optional, work on it after Replication is standardized
Volume QoS	?	admin only	needs further discussion, should be at least described

[fkr]

#323 is currently being discussed. Needs further discussion between commenting person and author.

[josephineSei]

Only a decision document was merged. The standard is still missing.

[fkr]

Only a decision document was merged. The standard is still missing.

oh. by bad! Thanks @josephineSei for watching this closely!

[josephineSei]

After reading through the proposal of @mbuechse I added a few comments to the hedgedoc. It seems we have two opposing approaches to standardization that both have positive and negative sides. But in the end, we seem to agree at least somehow on the result. It would be good to also include any conclusions into the standard-example file.