-
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
Add document for the volume type decisions #323
Conversation
This is part of ticket #265 |
Due to PTO this is on hold. Of course it is welcome to be further reviewed and commented, finalisation will happen once the participants is back. |
It was discussed that more and explicit feedback from operators is desired. |
My questions were all answered during an SCS call in which the topic was discussed. |
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.
Looks good to me from Operators point of view.
|
||
## Introduction | ||
|
||
Volumes in OpenStack are virtual drives. They are managed by the storage service Cinder, which abstracts creation and usage of many different storage backends. While it is possible to use a backend like lvm which can reside on the sam host as the hypervisor, the SCS wants to make a more clear differenciation between volumes and the ephemeral storage of a virtual machine. For all SCS deployments we want to assume that volumes are always residing in a storage backend that is NOT on the same host as a hypervisor - in short terms: Volumes are network storage. Ephemeral storage on the other hand is the only storage residing on a compute host. It is created by creating a VM directly from an Image and is automatically los as soon as the VM cease to exist. Volumes on the other hand have to be created from Images and only after that can be used for VMs. They are persistant and will remain in the last state a VM has written on them before they cease to exit. Being persistant and not relying on the host where the VM resides, Volumes can easily be attached to another VM in case of a node outage and VMs be migrated way more easily, because only metadata and data in RAM has to be shifted to another host, accelerating any migration or evacuation of a VM. |
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.
"For all SCS deployments we want to assume that volumes are always residing in a storage backend that is NOT on the same host as a hypervisor"
-> I hope this could not be misunderstood in connection with hyperconverged nodes where the (ceph-) volumes could reside on a ceph node that is compute node at the same time.
This document describes all options, that are configurable in volume types. It also shows our decisions and a few still open questions. This will be the base for the volume type standard. Signed-off-by: josephineSei <[email protected]>
Signed-off-by: josephineSei <[email protected]>
Signed-off-by: josephineSei <[email protected]>
…e-decisions.md change title Signed-off-by: josephineSei <[email protected]>
adding definition of volumes and section for "other backend-specific options". Signed-off-by: josephineSei <[email protected]>
fixed typo Signed-off-by: Markus Lindenblatt <[email protected]>
Co-authored-by: Felix Kronlage-Dammers <[email protected]> Signed-off-by: Markus Lindenblatt <[email protected]>
d75f0a9
to
7428fdb
Compare
This document describes all options, that are configurable in volume types. It also shows our decisions and a few still open questions. This will be the base for the volume type standard.