Feat: LVM as a pool backend #1587
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
tiagolobocastro
force-pushed
the
lvm
branch
5 times, most recently
from
43eecf0 to
1a65137
Compare
This was referenced Feb 16, 2024
tiagolobocastro
force-pushed
the
lvm
branch
5 times, most recently
from
1eb1e24 to
891b0ae
Compare
dsharma-dc
reviewed
Feb 23, 2024
hrudaya21
reviewed
Feb 23, 2024
hrudaya21
reviewed
Feb 23, 2024
tiagolobocastro
force-pushed
the
lvm
branch
2 times, most recently
from
95ee994 to
30fc472
Compare
dsharma-dc
approved these changes
Feb 26, 2024
Abhinandan-Purkait
approved these changes
Feb 26, 2024
tiagolobocastro
force-pushed
the
lvm
branch
3 times, most recently
from
735bad9 to
63d3d76
Compare
dsharma-dc
approved these changes
Feb 27, 2024
dsavitskiy
requested changes
Feb 27, 2024
|
This PR seems to be quite big and intrusive, and there are concerns about the implementation decisions, e.g. like communication with LVM with CLI tools, etc. |
tiagolobocastro
force-pushed
the
lvm
branch
3 times, most recently
from
64912ef to
702afdf
Compare
dsavitskiy
approved these changes
Apr 18, 2024
|
bors merge |
bors-openebs-mayastor bot
pushed a commit
that referenced
this pull request
Apr 18, 2024
1587: Feat: LVM as a pool backend r=tiagolobocastro a=tiagolobocastro Add LVM as an experimental alternative backend to Mayastor: 1. it allows us to use a low latency single replica local volume (app pinned to the same node) 2. robust backend for existing LVM users which may prefer it 3. combine local engines into mayastor This differs from the existing lvm localpv as rather than importing the existing VGs we create the LVM PV's and the LVM VG itself. On destruction, if the VG has no non-mayastor LVs then we destroy it, otherwise we leave it behind, untagged. The existing pool/replica services are also refactored to support adding other backends in the future as well. This is achieved by implementing the service interface separately and binding them at a higher level. This way it avoids mixing the backend code, at least as much as possible. Co-authored-by: Tiago Castro <[email protected]>
|
Build failed: |
|
bors merge |
|
🕐 Waiting for PR status (Github check) to be set, probably by CI. Bors will automatically try to run when all required PR statuses are set. |
bors-openebs-mayastor bot
pushed a commit
that referenced
this pull request
Apr 18, 2024
1587: Feat: LVM as a pool backend r=tiagolobocastro a=tiagolobocastro Add LVM as an experimental alternative backend to Mayastor: 1. it allows us to use a low latency single replica local volume (app pinned to the same node) 2. robust backend for existing LVM users which may prefer it 3. combine local engines into mayastor This differs from the existing lvm localpv as rather than importing the existing VGs we create the LVM PV's and the LVM VG itself. On destruction, if the VG has no non-mayastor LVs then we destroy it, otherwise we leave it behind, untagged. The existing pool/replica services are also refactored to support adding other backends in the future as well. This is achieved by implementing the service interface separately and binding them at a higher level. This way it avoids mixing the backend code, at least as much as possible. Co-authored-by: Tiago Castro <[email protected]>
|
bors cancel |
|
Canceled. |
|
bors merge |
bors-openebs-mayastor bot
pushed a commit
that referenced
this pull request
Apr 18, 2024
1587: Feat: LVM as a pool backend r=tiagolobocastro a=tiagolobocastro Add LVM as an experimental alternative backend to Mayastor: 1. it allows us to use a low latency single replica local volume (app pinned to the same node) 2. robust backend for existing LVM users which may prefer it 3. combine local engines into mayastor This differs from the existing lvm localpv as rather than importing the existing VGs we create the LVM PV's and the LVM VG itself. On destruction, if the VG has no non-mayastor LVs then we destroy it, otherwise we leave it behind, untagged. The existing pool/replica services are also refactored to support adding other backends in the future as well. This is achieved by implementing the service interface separately and binding them at a higher level. This way it avoids mixing the backend code, at least as much as possible. Co-authored-by: Tiago Castro <[email protected]>
|
Build failed: |
|
bors merge |
bors-openebs-mayastor bot
pushed a commit
that referenced
this pull request
Apr 18, 2024
1587: Feat: LVM as a pool backend r=tiagolobocastro a=tiagolobocastro Add LVM as an experimental alternative backend to Mayastor: 1. it allows us to use a low latency single replica local volume (app pinned to the same node) 2. robust backend for existing LVM users which may prefer it 3. combine local engines into mayastor This differs from the existing lvm localpv as rather than importing the existing VGs we create the LVM PV's and the LVM VG itself. On destruction, if the VG has no non-mayastor LVs then we destroy it, otherwise we leave it behind, untagged. The existing pool/replica services are also refactored to support adding other backends in the future as well. This is achieved by implementing the service interface separately and binding them at a higher level. This way it avoids mixing the backend code, at least as much as possible. Co-authored-by: Tiago Castro <[email protected]>
|
Build failed: |
Add LVM as an experimental alternative backend to Mayastor: 1. it allows us to use a low latency single replica local volume (app pinned to the same node) 2. robust backend for existing LVM users which may prefer it 3. combine local engines into mayastor This differs from the existing lvm localpv as rather than importing the existing VGs we create the LVM PV's and the LVM VG itself. On destruction, if the VG has no non-mayastor LVs then we destroy it, otherwise we leave it behind, untagged. The existing pool/replica services are also refactored to support adding other backends in the future as well. This is achieved by implementing the service interface separately and binding them at a higher level. This way it avoids mixing the backend code, at least as much as possible. Co-authored-by: shubham <[email protected]> Co-authored-by: Akhil Mohan <[email protected]> Co-authored-by: Tiago Castro <[email protected]> Signed-off-by: Tiago Castro <[email protected]>
Signed-off-by: Tiago Castro <[email protected]>
Supports using CARGO_VENDOR_DIR=/tmp/bob/.. in case bob doesn't exist. Probably won't ever happen but just in case :) Signed-off-by: Tiago Castro <[email protected]>
|
bors merge |
|
Build succeeded: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Add LVM as an experimental alternative backend to Mayastor:
local volume (app pinned to the same node)
This differs from the existing lvm localpv as rather than importing
the existing VGs we create the LVM PV's and the LVM VG itself.
On destruction, if the VG has no non-mayastor LVs then we destroy it,
otherwise we leave it behind, untagged.
The existing pool/replica services are also refactored to support
adding other backends in the future as well.
This is achieved by implementing the service interface separately
and binding them at a higher level. This way it avoids mixing
the backend code, at least as much as possible.