Closed tnthornton closed 2 weeks ago
Hi @tnthornton. Thanks for your PR.
I'm waiting for a kcp-dev member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test
on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test
label.
I understand the commands that are listed here.
/ok-to-test
LGTM label has been added.
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: embik
The full list of commands accepted by this bot can be found here.
The pull request process is described here
Currently, consumers of the KCP Helm chart are unable to specify a
StorageClass
to use with the EtcdStatefulSet
. This isn't a big deal in local dev environments. However with larger deployments where you need different storage types (e.g. SSDs), this can be problematic unless you change the default storageclass for the cluster - which has it's own impacts.This changeset enables specifying the
storageClassName
for the underlyingvolumeClaimTemplate
via the values.yaml or Helm override arg. I've explicitly opted to only use the storageClassName property if it's been set in the values.yaml, rather than specifying a default value in the values.yaml file. That way the current behavior continues to work and operators that need a more advanced setting are enabled to specify the target storageClass via the values.yaml.How has this been tested
I tested these changes against two clusters, kind and GKE. With the kind cluster, there's simply just the 1
StorageClass
that is included and available. Due to this, kind was used to test the basic case of not overriding the default behavior.Kind
myvalues.yaml
in order to closely following the local dev instructionsGKE
myvalues.yaml
to include the storageClass override