persistence as a globale parameter?

[3deep5me]

Hi Folks,

comin from community maintained nextcloud chart locking for some more cloud-native "Storage-Cloud".
Your Chart and the docs look good so far! ❤️
I try to configure this chart on my k8s, atm i configure the persistence Parameter, would it maybe be useful to have a global Parameter for persistence? Or maybe a "feature" for this.

[wkloucek]

Each persistence setting has a size option that needs to be set individually. For example the storage-users service has a default of 50Gi:

ocis-charts/charts/ocis/values.yaml

Line 668 in db68e76

size: 50Gi

Depending on your usecase this may be too much (eg when using the s3ng storage driver

ocis-charts/charts/ocis/values.yaml

Lines 609 to 612 in db68e76

	# -- Configures the storage driver. Possible values are "ocis" and "s3ng".
	# The oCIS driver stores all data in the persistent volume if persistence is enabled.
	# The S3NG driver stores all metadata in the persistent volume and uploads blobs to s3 if persistence is enabled.
	driver: ocis

) or way too less when using the ocis storage driver.

Therefore I would like people to have a look at each of the options and know that there are options than can be tuned.

Please also not that the current / only chart is aimed at large installations with many thousands of users. We already recognized that there is also a need for a different small instance (up to 100 users) chart (see #77). This specialized chart would start oCIS in a way that has a much smaller footprint and probably also only one PVC. I didn't come to creating a chart from owncloud/ocis#5053 because it has less in commonn with the current chart than I though.

[3deep5me]

@wkloucek
Thank you for your explanation this makes perfectly sense for me.
---spoiler---
I`m not that much in the architecture of owncloud so i can't assess how realistic this is:

What do you think of some example values which can just throw owncloud on a home-lab or small instances for companys which do not have the capacity to diggin deep into the documentation? Sure there will not be perfect fit for every use-case but maybe for the most common use-cases. Another advantage in comparison to a extra chart is that a company do not have to migrate the helm-chart if the deployment/users grows. For example bitnami-helmcharts can be normally installed in a working way with the default values. Normally i configure the values at this point to my needs and its much more easier if i can start from a working state😅. In short i think values which works direct, (example or default values) would lower the barrier to entry. (The entry hurdle to k8s is imo high enough)
If you maybe decide to do something like this, it would be pleasure to do a PR of this kind or maybe not even a PR but something you can maybe link in the documentation.

[wkloucek]

What do you think of some example values which can just throw owncloud on a home-lab or small instances for companys which do not have the capacity to diggin deep into the documentation? Sure there will not be perfect fit for every use-case but maybe for the most common use-cases.

Exactly that would be the benefit of the chart described in #77. It'll be designated to home / small oCIS setups. Currently we only have the chart for large / enterprise setups.

Another advantage in comparison to a extra chart is that a company do not have to migrate the helm-chart if the deployment/users grows.

I fear that this would make the chart described in #77 complicated, too. I personally would prefer a dead simple deployment in #77 and a migration would be possible anyways, but not by just switching the chart.

For example bitnami-helmcharts can be normally installed in a working way with the default values. Normally i configure the values at this point to my needs and its much more easier if i can start from a working statesweat_smile. In short i think values which works direct, (example or default values) would lower the barrier to entry. (The entry hurdle to k8s is imo high enough) If you maybe decide to do something like this, it would be pleasure to do a PR of this kind or maybe not even a PR but something you can maybe link in the documentation.

From my point of view, the main problem when starting with this chart is configuring all secrets (tracked in #50).

[3deep5me]

Good point with the Secrets. Maybe i will investigate in #50, the simple deployment would have the same problems or do you have a plan how to mange these secrets on the simple chart? The best thing i am thinking about right now could be a Job which manages the Secrets direct over the k8s-api.