mayastor
mayastor copied to clipboard
openebs
Feat: LVM as a pool backend
Add LVM as an experimental alternative backend to Mayastor:
- it allows us to use a low latency single replica local volume (app pinned to the same node)
- robust backend for existing LVM users which may prefer it
- 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.
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. Shouldn't we go through our full feature design process as we do for other features? HLD, LLD, BDDs, and so on.
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. Shouldn't we go through our full feature design process as we do for other features? HLD, LLD, BDDs, and so on.
This is a re-raise of existing PR's which did not get merged (not sure if there was a design for that or not, probably left in the old wiki), so we're finally merging them now (with a rebase and refactor). This is an experimental feature and not enabled by default.
My point is that maybe it is worth it to have a couple of meetings to (re-)review the current design? Besides low level implementation considerations, there are a couple of topics that are potentially affected by LVM backend:
- Replica/volume expansion.
- Disk aggregation.
My point is that maybe it is worth it to have a couple of meetings to (re-)review the current design? Besides low level implementation considerations, there are a couple of topics that are potentially affected by LVM backend:
* Replica/volume expansion. * Disk aggregation.
Makes sense, I've sent an invite post-standup tomorrow
![bors-openebs-mayastor[bot] avatar](https://avatars.githubusercontent.com/u/20769039?v=4 "Published by a pub.dev verified publisher"){kind=small}
:clock1: 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.