Skip to content
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

Merged
merged 7 commits into from
Sep 13, 2023
Merged

Add document for the volume type decisions #323

merged 7 commits into from
Sep 13, 2023

Conversation

josephineSei
Copy link
Contributor

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.

@josephineSei
Copy link
Contributor Author

This is part of ticket #265

@fkr fkr added IaaS Issues or pull requests relevant for Team1: IaaS Sprint Gothenburg Sprint Gothenburg (2023, cwk 28+29) labels Jul 19, 2023
@fkr fkr added this to the R5 (v6.0.0) milestone Jul 19, 2023
@fkr fkr requested review from fkr and berendt July 19, 2023 08:31
@fkr
Copy link
Member

fkr commented Jul 26, 2023

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.

@garloff garloff added the standards Issues / ADR / pull requests relevant for standardization & certification label Aug 18, 2023
@josephineSei
Copy link
Contributor Author

@berendt @fkr i added a section with "other options" to conclude, that backend specific but notable options should ideally be noted in the description by the deployers themself. Are you okay with that? It would solve many discussion points.

@fkr fkr requested review from berendt, maliblatt and jnull August 30, 2023 13:42
@fkr
Copy link
Member

fkr commented Sep 6, 2023

It was discussed that more and explicit feedback from operators is desired.
As such @jnull and @maliblatt were added as reviewers. Please review in the course of the next six days.

@berendt
Copy link
Contributor

berendt commented Sep 12, 2023

My questions were all answered during an SCS call in which the topic was discussed.

Copy link
Contributor

@maliblatt maliblatt left a 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.
Copy link
Contributor

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.

josephineSei and others added 7 commits September 13, 2023 10:19
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]>
…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]>
@fkr fkr force-pushed the volume-type-decisions branch from d75f0a9 to 7428fdb Compare September 13, 2023 08:19
@fkr fkr merged commit 5b22c96 into main Sep 13, 2023
@fkr fkr deleted the volume-type-decisions branch September 13, 2023 08:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
IaaS Issues or pull requests relevant for Team1: IaaS Sprint Gothenburg Sprint Gothenburg (2023, cwk 28+29) standards Issues / ADR / pull requests relevant for standardization & certification
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

5 participants