Decide on better defaults for apps settings #171

New Issue

knoflook · 2021-09-15T09:06:42Z

knoflook commented

2021-09-15 09:06:42 +00:00

I was trying to deploy nextcloud and the default PHP settings aren't the best IMO. We should have a model server configuration for writing configs. The default php-fpm.ini (for nextcloud) assumes a server with roughly 5-6GB of RAM and more or less 8 cores. I propose we try keeping the defaults more sane so that the apps can be ran on f1-s capsul (1 core, 1GB of memory) and where it's not possible, inform the user in README and give them minimum requirements. Also this should appear in the docs.
I'm choosing f1-s capsul as a model because if you need more power that means you'll have more users so you likely have more experience and will not be intimidated by editing config files and will be able to judge i.e. how many children can php-fpm spawn.

Maybe in the future we can have different configs for different capsul/servers.coop tiers? And then deploy apps from the servers.coop web interface with the config appropriate for a specific tier? :> that's not critical now though.

I was trying to deploy nextcloud and the default PHP settings aren't the best IMO. We should have a model server configuration for writing configs. The default php-fpm.ini (for nextcloud) assumes a server with roughly 5-6GB of RAM and more or less 8 cores. I propose we try keeping the defaults more sane so that the apps can be ran on f1-s capsul (1 core, 1GB of memory) and where it's not possible, inform the user in README and give them minimum requirements. Also this should appear in the docs. I'm choosing f1-s capsul as a model because if you need more power that means you'll have more users so you likely have more experience and will not be intimidated by editing config files and will be able to judge i.e. how many children can php-fpm spawn. Maybe in the future we can have different configs for different capsul/servers.coop tiers? And then deploy apps from the servers.coop web interface with the config appropriate for a specific tier? :> that's not critical now though.

knoflook added the

documentation

design

abra

labels 2021-09-15 09:06:42 +00:00

decentral1se commented

2021-09-15 10:28:41 +00:00

Nice.

Yes right, I remember discussing this at some point. It would totally make sense to parametrize the type of configs that are loaded in based on the system requirements. That would be amazing.

I could imagine a ${STACK_NAME}_{SIZE}_MY_CNF_${VERSION} or something where ${SIZE} can be configured? Then we'd have a conf/ folder in the recipes to match {small,medium,large} or whatever.

This hooks into #29 and #65 I think. We probably want to have a sliding scale for the app limits also based on the system requirements?

It'd be nice to come up with a plan for this soon.

Nice. Yes right, I remember discussing this at some point. It would totally make sense to parametrize the type of configs that are loaded in based on the system requirements. That would be amazing. I could imagine a `${STACK_NAME}_{SIZE}_MY_CNF_${VERSION}` or something where `${SIZE}` can be configured? Then we'd have a `conf/` folder in the recipes to match `{small,medium,large}` or whatever. This hooks into https://git.coopcloud.tech/coop-cloud/organising/issues/29 and https://git.coopcloud.tech/coop-cloud/organising/issues/65 I think. We probably want to have a sliding scale for the app limits also based on the system requirements? It'd be nice to come up with a plan for this soon.

decentral1se added this to the Portability testing (software/hardware) milestone 2021-09-15 10:30:46 +00:00

3wordchant changed title from ~~Decide on sane defaults for apps settings~~ to Decide on better defaults for apps settings

2021-09-16 13:22:50 +00:00

decentral1se added this to the Beta release (software) project 2021-11-09 10:30:28 +00:00

decentral1se commented

2022-02-09 17:47:57 +00:00

I think we can resolve this just by doubling down on dding hooks into the configs of each recipe via the env vars. At this point, doing something like #171 (comment) would likely break more than it would do good. So, just parametrizing values in configs seems the safest.

I think we can resolve this just by doubling down on dding hooks into the configs of each recipe via the env vars. At this point, doing something like https://git.coopcloud.tech/coop-cloud/organising/issues/171#issuecomment-8957 would likely break more than it would do good. So, just parametrizing values in configs seems the safest.

decentral1se removed this from the Beta release (software) project 2022-02-09 17:48:07 +00:00

decentral1se removed this from the Portability testing (software/hardware) milestone 2022-02-09 17:48:10 +00:00

decentral1se commented

2022-03-11 11:07:51 +00:00

#171 (comment)

https://git.coopcloud.tech/coop-cloud/organising/issues/171#issuecomment-12034

decentral1se closed this issue

2022-03-11 11:07:51 +00:00

Sign in to join this conversation.

No Milestone

No project

No Assignees

2 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: coop-cloud/organising#171