Workaround to set IOPS, BPS limit for Pod accessing a Volume

[abhranilc]

Pull Request template

Please, go through these steps before you submit a PR.

Why is this PR required? What issue does it fix?:
Currently there is no way to limit Iops for a Pod on LVs created on a physical volume thereby making it impossible for multiple Pods to use respective LVs on a shared physical volume with iops limits or guarantees.

What this PR does?:
This PR introduces change to set an optional parameter --setiolimits in open-lvm-plugin container along with some static iops rates configured for volume groups. This is used

Does this PR require any upgrade changes?:
CSIDriver.Spec needs to be updated in lvm-operator deployment to make podInfoOnMount: true. If not, then while attempting to set io limits, a Warning will be logged as pod.uid will not be available in NodePublishVolume gRPC request.

New CSIDriver definition:

Create the CSI Driver object

apiVersion: storage.k8s.io/v1
kind: CSIDriver
metadata:
name: local.csi.openebs.io
spec:

do not require volumeattachment

attachRequired: false
podInfoOnMount: true

New definition for openebs-lvm-container:
- name: openebs-lvm-plugin
securityContext:
privileged: true
allowPrivilegeEscalation: true
image: abhranilc/lvm-driver:iops-test9
imagePullPolicy: IfNotPresent
args:
- "--nodeid=$(OPENEBS_NODE_ID)"
- "--endpoint=$(OPENEBS_CSI_ENDPOINT)"
- "--plugin=$(OPENEBS_NODE_DRIVER)"
- "--setiolimits"
- "--container-runtime=$(CONTAINER_RUNTIME)"
- "--riops-per-gb=$(RIOPS_PER_GB)"
- "--wiops-per-gb=$(WIOPS_PER_GB)"
env:
- name: OPENEBS_NODE_ID
valueFrom:
fieldRef:
fieldPath: spec.nodeName
- name: OPENEBS_CSI_ENDPOINT
value: unix:///plugin/csi.sock
- name: OPENEBS_NODE_DRIVER
value: agent
- name: LVM_NAMESPACE
value: openebs
- name: CONTAINER_RUNTIME
value: containerd
- name: RIOPS_PER_GB
value: lvmvg1:65,lvmvg3:60
- name: WIOPS_PER_GB
value: lvmvg1:70,lvmvg3:65

If the changes in this PR are manually verified, list down the scenarios covered::
Scenario 1: setting io limits not enabled, no change in expected behaviour
Scenario2: setting only iops
Scenario3: setting both iops, bps

Any additional information for your reviewer? :
Mention if this PR is part of any design or a continuation of previous PRs
This PR uses changes in openebs-lib-csi PR openebs/lib-csi#3

Checklist:

• Fixes #
• [Y ] PR Title follows the convention of <type>(<scope>): <subject>
• [ N] Has the change log section been updated?
• [ Y] Commit has unit tests
• [ N] Commit has integration tests
• (Optional) Are upgrade changes included in this PR? If not, mention the issue/PR to track:
• [ N] (Optional) If documentation changes are required, which issue on https://github.com/openebs/openebs-docs is used to track them:

PLEASE REMOVE BELOW INFORMATION BEFORE SUBMITTING

The PR title message must follow convention:
<type>(<scope>): <subject>.

Where:

• type is defining if release will be triggering after merging submitted changes, details in CONTRIBUTING.md.
  Most common types are:

  • feat - for new features, not a new feature for build script
  • fix - for bug fixes or improvements, not a fix for build script
  • chore - changes not related to production code
  • docs - changes related to documentation
  • style - formatting, missing semi colons, linting fix etc; no significant production code changes
  • test - adding missing tests, refactoring tests; no production code change
  • refactor - refactoring production code, eg. renaming a variable or function name, there should not be any significant production code changes

• scope is a single word that best describes where the changes fit.
  Most common scopes are like:

  • data engine (localpv, jiva, cstor)
  • feature (provisioning, backup, restore, exporter)
  • code component (api, webhook, cast, upgrade)
  • test (tests, bdd)
  • chores (version, build, log, travis)

• subject is a single line brief description of the changes made in the pull request.

[pawanpraka1]

@abhranilc what will happen if I have not set the limits for few volume groups?

[pawanpraka1]

looks good.