1. Proposed title of this feature request
Support with LVM Operator multiple LVMCluster instances across different namespaces
2. What is the nature and description of the request?
Manage and support with LVM Operator multiple LVMCluster instances across different namespaces, allowing:
- Independent configurations per namespace.
- Ability to target different node sets for different workloads.
- Greater flexibility for multi-tenant or multi-use-case environments.
3. Why does the customer need this? (List the business requirements here)
We are currently using the LVM Operator on OpenShift clusters to deploy and manage LVM storage (for example to leverage NVMe storage for Azure L-series nodes).
The operator consumes a custom resource called LVMCluster, which is a namespaced resource. However, the current limitation is that only one LVMCluster instance can exist per cluster, regardless of namespaces.
This design significantly restricts flexibility because:
- All configuration is centralized in a single LVMCluster resource.
- We can customize storage for one use case, but cannot adapt configurations for multiple distinct use cases.
- If we want different sets of nodes for different workloads, it is not possible under the current design.
Business impact
For example, my customer is using LVM Operator for Splunk in its dedicated namespace. However, he cannot extend this approach to other workloads (e.g., logging, analytics, or application-specific storage) because of the single-instance limitation.
Objectives of this RFE
- Improve scalability and isolation for workloads.
- Allow better utilization of NVMe storage on Azure L-series nodes, but any cloud provider exposing VM with local storage
- Align with OpenShift’s multi-namespace architecture for operators and resources.
4. List any affected packages or components.
- LVM Operator