search

openebs / lvm-localpv

Dynamically provision Stateful Persistent Node-Local Volumes & Filesystems for Kubernetes that is integrated with a backend LVM2 data storage stack.
Apache License 2.0
245 stars 92 forks source link

chore(snapshot): adding the design doc for mountable snapshots #183

Open wowditi opened 2 years ago

wowditi commented 2 years ago

Pull Request template

Please, go through these steps before you submit a PR.

Why is this PR required? What issue does it fix?:

What this PR does?: It adds a design for a new feature

Does this PR require any upgrade changes?: No

If the changes in this PR are manually verified, list down the scenarios covered::

Any additional information for your reviewer? : In the drawbacks section I posed the question of whether we should maybe use annotation to indicate that we are mounting a snapshot instead of creating a new PV as a clone of the snapshot. I'd like a second opinion on whether this is a good idea or what a good alternative could be (for example, we could create a new api-resource although I don't think that would be such a good idea). Also a PVC requires the Storage to be set, however, it is a little bit useless in this case especially when mounting snapshots. Any suggestions on handling that better would be appreciated.

Checklist:

Abhinandan-Purkait commented 11 months ago

@wowditi Can you please provide an update on the plans for taking this forward? Are you willing to work on this?

orville-wright commented 5 months ago

Hi @wowditi I run Product Mgmt for the OpenEBS project. You've put a lot of amazingly impressive & detailed work into your PR and it received a bunch of good reviews from our ENG team. Overall very positive. LVM-localPV is now getting a major focus in the OpenEBS product as it's being unified into the core platform as a central component, rather than being managed as a separate external Data-Engine. Additionally, LVM-LocalPV now has ~50,000 Daily Active Users and +150,000 product installations. So it's now a very well validated part of the platform. Hence we're are unifying it into the main product.

We'd really like to work on developing your PR and integrate the design into the new unified product.

Are you still interested and willing to support your PR?

wowditi commented 5 months ago

Hi, Sorry I forgot about this since my company started using the ZFS variant since it already had the features we need. I do not have a lot of spare time currently, but I could probably help since it wasn't that much work from what I remember.

About the design document, the implementation details are indeed very technical currently and I can make those a bit more high level. After using the ZFS localpv I also noticed that this is basically the same behaviour as what they refer to as cloning, should I rewrite the document to call it cloning and remove the drawback?

PS: I should probably mention that I mainly code in python and not Golang, so it might not be the most beautiful code.

dsharma-dc commented 2 months ago

I see at least a few things that aren't talked about in this document:

  1. There is an idea in the document that if the PVC for snapshot is created with a capacity(resource) - we could extend the lvm if the defined storage size is larger then that of the snapshot (with a maximum of the size of the original volume). If the snapshot is thick and is extended to a cap of original LV size, it'll become invalid in view of LVM. How do we deal with that during PVC provisioning.
  2. If say there is a volume V1 of size S, a snapshot of V1 is created of size 50% i.e. S/2. Now a PVC P is provisioned with snapshot. If the snapshot is configured to auto-extend, the snapshot size at some point becomes larger than size of P. How does that affect the pvc P ?
  3. If a mounted snapshot becomes invalid (100% of original LV size), how does that impact the pvc which is bound to it?
dsharma-dc commented 2 weeks ago

This hasn't yet progressed based on last set of clarifying questions. Keeping a track of it.