Expected Storage Classes (documentation and minimising developer profile dependencies)

[allanbarklie]

I think this is a great initiative. I'm initially interested in the developer profile.

I'm using Docker Desktop, the Kubernetes cluster by default only has the Storage Class 'hostpath' I note that the developer profile relies on the existence of both 'hostpath' and 'standard'

At least one other storage class is introduced in the other profiles 'ssd' It would be good to document these and consider if the developer profile should/could only need 'hostpath' by default.

[salaboy]

@allanbarklie that is definitely a good suggestion. Would you mind sending a PR for supporting setting 'hostpath' in our current charts? So we standardize that for local development.

[allanbarklie]

@salaboy I'm new to charts so just finding my feet.

From some more experimenting and reading my updated understanding is that a k8s cluster can have a default storage provider. If any persistentvolumeclaim (including a template) leaves storage class blank (not an empty string, actually blank) then the default storage provider will be used.

For docker desktop that is a storage provider called hostpath that uses the provisioner docker.io/hostpath For GKE I believe the default storage provider is called standard

In the current version when I run it on docker desktop the zeebe broke ends up with a volume backed by hostpath it gets that by leaving the storage class blank, as the current dev profile Helm chart does not set the Zeebe chart configuration field pvcStorageClassName

I would guess that when this is run on GKE standard is used.

For elastic search the dev profile is currently explicitly setting standard, if instead storage class is left blank then on my system with docker desktop it successfully uses hostpath

I would guess that on GKE this will continue to use standard.

In my test I changed (in zeebe-dev-profile.yaml)

# Request smaller persistent volumes.
    volumeClaimTemplate:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "standard"
      resources:
        requests:
          storage: 100M

to

# Request smaller persistent volumes.
    volumeClaimTemplate:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName:
      resources:
        requests:
          storage: 100M

If this sounds sensible I can commit the tweak and submit for the PR?

[salaboy]

@allanbarklie totally.. I think that is a safe thing to do.. did you tried without thestorageClassName property? does it complain?

[allanbarklie]

@salaboy - just tried it, leaving the storageclassName out entirely works fine and I agree that is cleaner

[salaboy]

@allanbarklie can you please send a PR with that change? it will be highly appreciated!

[allanbarklie]

@salaboy Sure, where would you like the code for the PR pushed to?

[salaboy]

@allanbarklie where is your change exactly? Is it only here -> https://github.com/zeebe-io/zeebe-helm-profiles/blob/master/zeebe-dev-profile.yaml#L28 ?

[allanbarklie]

@salaboy yes it is just deleting that line

[salaboy]

@allanbarklie so send the PR to this repo then.. :)

[allanbarklie]

@salaboy sorry I should have been more explicit in my where to push to question, I don't have permission to create a branch and forking the repo feels a bit heavyweight - are you able to either grant permission or create me a branch?

[salaboy]

@allanbarklie we all work by forking.. for such a small change.. if you try to change the file here.. github will offer you to create a fork plust a branch and then a PR from it, it should be pretty straight forward.

[upgradingdave]

Hi all, we have re-organized this repo and have updated the development helm profiles with a storage class that should work with KIND for local development. Closing for now, thanks!