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
235 stars 92 forks source link

make volgroup and vgpattern optional args for volume provisioning #312

Open abhilashshetty04 opened 3 weeks ago

abhilashshetty04 commented 3 weeks ago

Following are the current behavior.

  1. volgroup or vgpattern are mandatory patten in sc for lvm localpv to provision volume successfully.

    1. If only one of this pattern is specified, Then lvm local pv assumes that the vg matching the pattern is available on all lvmnodes. Otherwise, User have to explicitly define which node has spcified vg using node topology. Its not easy User experience.

    2. This behaviour sort of mandates user to preprovision vg with specific vg name on all nodes. If they have a plan to have vg name unique accress lvmnodes then they have to sc specfic to the vg with node topology.

    4.If user has unique vg name across nodes and creates a sc with volgroup for specific vg. Then provisioner will create lvmvolume cr anyway on some node without checking if that node has vg specified in sc parameter. The cr is picked by a node plugin which is set in owner field. It marks CR as error as vg is not available. Then provisioner sees the error on CR deletes CR and returns ResourceExhausted grpc Response.

    1. If user created a sc with volgroup which doesnt exist in any node. Then also lvmvolume cr is created on any node randomly. The creation will fail and cr is deleted. If user creates a vg before a retry of /CreateVolume is received. It doesnt pick the node it picked before. Its as if not trying to schedule on the node where vg is present(unless vg with that name is present on all node and node topology is not given).

    2. If all node has vg specified in sc. However, pvc is requesting volume size which no vg can accomodate. Then also lvmvolume cr is created and it follows same path where error is appended on cr by node plugin and deleted with ResourceExhaused.

Im suggesting following change:

1. Make volgroup and vgpattern not a mandatory paramater in storage class for volume provisioning. If user have not preovided anyof these 2 params and no topology constraint. Schedular can place lvmvolume on any node any vg.

2. If user specified volgroup/vgpattern then provisioner should take that into consideration. Even if no topology specified, Provisioner should not expect vg to be present on all node. If it cant find vg in any node then it should fail fast (Dont create CR also return ResourceExhausted allowing further retires. Meanwhile if user creates new vg on any node that match the pattern then lvmvolume should be provisioned on that node.

3. If user creates sc with volgroup/vgpattern, has node topologies also set to a particular node/s. Then strictly adhere to that. 

4. Dont create lvmvolume CR if no vg in the cluster can accomodate the volume due to the size requested in pvc. Today, We pick node mostly based on scheduling alorithm and dont factor in the pvc size requirement. We should Fail with ResourceExhausted. Allowing retry.

Anything else you would like to add: Following link has details of some scenario that i tested. https://gist.github.com/abhilashshetty04/dcb73d32a8c6eecbe3160629b9be4f52