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

[avishnu]

Thanks for your insights, @Alex130469 and @orville-wright .
The core team (which includes most of the maintainers and core contributors) are working towards creating a realistic and sustainable near-term roadmap for OpenEBS which includes features and enhancements for the localpvs (hostpath, lvm, zfs, rawfile) and Mayastor. As a part of this exercise, we are going through every user request in the relevant project repositories, prioritizing them on factors like impact, criticality, estimate T-shirt sizes and complexity and assigning them to upcoming OpenEBS milestones (v4.x).

The current issue is a good-to-have enhancement, but not a blocker or must-have for the users. LVM and ZFS are very popular storage technologies, administrators are well-versed in these stacks and can easily configure the required Volume Groups and ZPools as per their needs. This has been the premise on which the localpv-lvm and localpv-zfs came into existence. There will be considerable amount of effort needed in providing the requested functionality on the localpv drivers, as mentioned in this comment (#245 (comment)).

For now, this is likely to be of lesser priority. Once the roadmap is drafted, it will be presented to all the maintainers for their review, where this issue can be discussed if need be. Meanwhile, community contributions are always welcome.