Lvm driver should create volume group and pvc. User should not manually create it.

[yash97]

Describe the problem/challenge you have
[A description of the current limitation/problem/challenge that you are experiencing.]
Right now user has to manually create lvm volume as per my understanding. This should not be the case imo. Lvm driver should create it based on config.

[abhilashshetty04]

@yash97 Thanks for raising the requirement. However, creating PV / VG using LVM localPV is not straight forward tasl. We dont have upstream caller like for LV (volume). We would need to create custom resource for them and reconciler as well. In that case also you need to create Custom resources anyway. So it seems easier to preprovision PV / VG as we do now.

[Abhinandan-Purkait]

@yash97 Although if you want to contribute, can you please raise a design document for the same so that we can review and plan accordingly? Thanks

[orville-wright]

@yash97
@abhilashshetty04

We've just coded the LVM Dynamic auto-provisioning feature for Mayastor, and enabled it as an experimental feature.

That new code now auto-provisions all LVM entities (PV, VG and LV) and the Filesystem. - There is no need for manual LVM provisioning by the user.

The code is currently being tested as part of Mayastor as an evolution of our DiskGroup. You can now have SPDK or LVM backend managed storage.

Now that we have all that auto-provisioning logic coded, our plan is to roll that in to the LVM-LocalPV Data-Engine also.

Irrespective of what the CSI spec says, we strongly believe that our user experience strategy should be that the user will never need to manually interact with LVM at all and all LVM backend tasks will be dynamically automated by OpenEBS.

note: The current code doesn't allow RAIDed LV's yet. That's definitely coming next. (we're also enabling the same Dynamic auto-provisioning for ZFS-LocalPV too.

Also, Issue #164 also relates directly to this issue as #164
aspires to enable RAID (0/1/5/10) LV's. Both are needed together to enable complete utilization of LVM.

Hope this helps.

[Alex130469]

Hello!

I am the new PM for the OpenEBS project at DataCore and wanted to shed some light on the discussion above.

When it comes to managing LVM PVs and VGs, we intend to keep this management outside of the core OpenEBS scope. LocalPV and Mayastor may create LVs on top of pre-created VGs but for now will not create and manage the VGs themselves. This is similar to the approach we have for ZFS where we start acting at the zVol provisioning level but not deal with creation and management of the zPool itself.

Hope this helps.

[orville-wright]

Hi @Alex130469 - Dave here (@orville-wright ), Maintainer of our OpenEBS CNCF opensource project.

Thanks for the Issue comment & update.

I think our CNCF OpenEBS opensource community may appreciate a little extra info/clarity...

1. Its unclear if your speaking for/about Datacore's private commercial closed-source version of OpenEBS; or our community's opensource OpenEBS project ?
2. Our CNCF opensource OpenEBS project is strictly guided by our CNCF aligned Governance docs. One critically important governance doc is our VISION doc. The VISION doc defines what is in-scope and out-of-scope for our opensource project as we (Maintainers) make roadmap feature decisions. All Roadmap/feature decisions are aligned with our VISION rules.
   • Since this LVM feature has been heavily requested & discussed by our opensource community for some time... please help our opensource community understand how your LVM PV & VG feedback is connected to our VISION guidelines/rules.
   • https://github.com/openebs/community/blob/develop/VISION.md
3. note to our community: OpenEBS Maintainers manage project Roadmap decisions & direction (as per Governance docs). This decision was reviewed & approved by the Maintainers

@avishnu @niladrih @abhilashshetty04