RFE: Creating an API and Controller for managing VolumeGroups

[jakobmoellerdev]

What should the feature do:

• As a TopoLVM API user, I want all pertinent data for Volume Groups and Nodes readily available in one location in Kubernetes. Having a centralized place for all related information will improve usability and make the process of managing storage configurations more straightforward and efficient.
• As a TopoLVM API user, I want to utilize my preexisting knowledge of Kubernetes APIs to configure lvm volume groups. Leveraging knowledge I already have will reduce the learning curve and allow me to work more effectively and efficiently without leaving the cluster context.
• As a cluster administrator, I want to allow users that do not have host access to configure volume groups without accessing the host operating system on a node.
• As a cluster administrator, I wish to have the flexibility to deploy multiple configurations of volume groups without reconfiguration of the host operating system on a node.

What is the use case behind this feature:

It has been a long time since LVMS became a downstream of TopoLVM. I would like to think of a day where we can get rid of the alpha APIs of LVMS alltogether and allow full Volume Group Configuration from within TopoLVM. This would go beyond the classic integration of a CSI Driver and allow extend the topolvm-controller to control Volume Group Management, not just Logical Volumes.

I want to use this feature to collect necessary steps or criticism and other feedback towards creating a joint effort for a Volume Group API that is able to be used with Logical Volumes together.

[peng225]

Because I do not have time to think about this issue, I would appreciate it if you could wait until next week.

[jakobmoellerdev]

I dont think we have to go fast on this. We should take our time and I can create a draft RFE as well if necessary

[peng225]

@jakobmoellerdev
Thank you for your proposal. Let me ask some questions.

• What do you mean by saying "a TopoLVM API user"? Is that people who want to provision volumes via TopoLVM, or the storage administrator?
• I think it is a strong privilege for TopoLVM users to be able to configure volume groups. Perhaps, it may be good to allow VG configuration to a limited number of people like cluster administrators. What do you think about the privilege management of VGs?
• In my environment, VG configuration is rarely changed. Could you provide me with some use cases where TopoLVM users want to configure VGs?

[jakobmoellerdev]

* What do you mean by saying "a TopoLVM API user"? Is that people who want to provision volumes via TopoLVM, or the storage administrator?

That is people who administrate TopoLVM. Usually that equals the storage administrator but sometimes the underlying disk/hardware are managed by different people than those who maintain the cluster.

* I think it is a strong privilege for TopoLVM users to be able to configure volume groups. Perhaps, it may be good to allow VG configuration to a limited number of people like cluster administrators. What do you think about the privilege management of VGs?

I totally agree, there should be a separate set of permissions for VolumeGroup Management that is decoupled from LogicalVolume / PVC consumption. It is an administrative task

* In my environment, VG configuration is rarely changed. Could you provide me with some use cases where TopoLVM users want to configure VGs?

I agree that VG configuration rarely changes. However the main use case for us is actually people who want to drive configuration-based clusters. Meaning that they do not want to rely on the correct configuration of the Operating System underneath and want to be able to spin up a cluster from scratch without having to setup custom scripts for checking volume groups on the Host OS. Most newer container platforms run on immutable Filesystems so the incentive is high to move all LVM management from the Host OS to TopoLVM.

[peng225]

Thank you for your explanation.
It looks good to me.

I would also like to hear from the other maintainers, but some of them are out sick.
So, please wait until next week.

[peng225]

@jakobmoellerdev
I discussed this topic with other maintainers. Let me ask some additional questions.

• There is a way to create a controller to manage VG as a separate repository in TopoLVM org. What do you think about separating the existing TopoLVM controller and the controller for VG management?
  • As background, we have been trying to keep the code base simple by reducing the scope of the problem TopoLVM solves.
  • If it is separated into different controllers, the VG controller can also be used for other TopoLVM-like CSI drivers, which would make it more versatile.
• Creating VG from PV depends on the environment, so it seems to be difficult to create such APIs. Even if we initially target only a specific environment, we are concerned that later requests for support of various environments will emerge and complicate the code base. How do you think about it?

[jakobmoellerdev]

I think those are valid concerns and at least I would be open to create a new upstream repository for it. My question would be how TopoLVM and this new Repo then integrate. After All, most people expect volume group management when they deal with LVM out of the box. I would like to see a world in which this can be deployed as one unit.

I have some questions on the argumentation

As background, we have been trying to keep the code base simple by reducing the scope of the problem TopoLVM solves.

I agree that this is a concern, but maybe we should define (separately from this issue) a list of features that we slowly want to phase out, deprecate and remove in favor of new features that are desired by users?

If it is separated into different controllers, the VG controller can also be used for other TopoLVM-like CSI drivers
Which "other TopoLVM-like CSI drivers" would we talk about here? I am concerned that scoping the project too generically will not solve our desire to ease up the complexity of the code base.

[peng225]

@jakobmoellerdev Thank you for your reply.

My question would be how TopoLVM and this new Repo then integrate.

One idea is that the new VG controller creates a VG on the node based on the new VolumeGroup custom resource, and TopoLVM should work as before with the VG. There may be a better way, though.

After All, most people expect volume group management when they deal with LVM out of the box. I would like to see a world in which this can be deployed as one unit.

I agree that it would be more user-friendly if the VG controller and TopoLVM's existing controller were integrated. What I'm concerned is whether it is possible to achieve such an architecture without complicating the system. I would like to know if you have any vision about what the new VG controllers API would look like.

but maybe we should define (separately from this issue) a list of features that we slowly want to phase out, deprecate and remove in favor of new features that are desired by users?

This seems like a good idea. Though I don't know if there are any features that we can stop supporting, it seems worth thinking about continuously since we don't have given much thought to dropping supported features.
(Also, I agree that it should be done somewhere other than this issue.)

[jakobmoellerdev]

I would like to know if you have any vision about what the new VG controllers API would look like.

I had an idea in the past of how to refactor the current LVM Management in LVMS that might be of relevance here: https://github.com/openshift/lvm-operator/blob/main/docs/design/proposals/logical-volume-manager-storage-api-v2.md

The idea here was to use a LVMNode to determine the deviceClasses and VolumeGroups which would be created under the hood. However I think we could easily switch to a more fine grained control by introudcing a VolumeGroup CRD with a controller as well at first and then introduce an even higher abstraction resource such as LVMNode later if desired.

I have various Ideas here and can come up with a design proposal that accomodates the wishes mentione here.

[peng225]

@jakobmoellerdev

I have various Ideas here and can come up with a design proposal that accomodates the wishes mentione here.

Thanks. I would be glad if you could prepare a proposal document.

I’d like to explore different ideas and understand their advantages and disadvantages.
(For example, if the VG controller is separated from the TopoLVM controller, what is good and bad? Which is better to introducing VolumeGroup CR or LVMNode CR? etc.)

[github-actions]

This issue has been automatically marked as stale because it has not had any activity for 30 days. It will be closed in a week if no further activity occurs. Thank you for your contributions.