fix(helm): remove CRDs already part of kubernetes-csi/external snapshotter

[rhr323]

Why is this PR required? What issue does it fix?:

The helm chart includes CRDs that are part of kubernetes-csi/external-snapshotter. This causes some confusion when the CRDs are installed from two different sources.

What this PR does?:

This PR removes the CRDs that are already part of other kubernetes components.

Does this PR require any upgrade changes?:

Helm does not remove CRDs, so no longer having the CRDs in the helm chart should not cause any issues.

If the changes in this PR are manually verified, list down the scenarios covered::

Any additional information for your reviewer? :

This is a proposal, and would be happy to receive feedback, and/or understand the original reason why the CRDs have been duplicated to the helm chart of openebs/lvm-localpv.

Checklist:

• [ ] Fixes #
• [x] PR Title follows the convention of <type>(<scope>): <subject>
• [ ] Has the change log section been updated?
• [ ] Commit has unit tests
• [ ] Commit has integration tests
• [ ] (Optional) Are upgrade changes included in this PR? If not, mention the issue/PR to track:
• [ ] (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.

[rhr323]

Hey @niladrih , thanks for the response!

Maybe an other solution could be to wrap the CRDs in question, for example:

{{- if .Values.k8sStorageCrds.create }}
---
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: volumesnapshotclasses.snapshot.storage.k8s.io

....

{{- end }}

This way, users of openebs could decide whether they would like to install those CRDs or not... What do you think?

[niladrih]

Sounds good to me @rhr323 . Let's leave installation on by default though...

[niladrih]

@rhr323 this change has been included in PR https://github.com/openebs/lvm-localpv/pull/243, closing this one.