lunny/helm-chart
1
0
Fork 0
Code Issues 36 Pull Requests 14 Actions Packages Projects Releases 93 Wiki Activity

How to configure external applications? #489

New Issue
Closed
opened 2023-08-24 01:58:44 +00:00 by fbongiovanni29 · 11 comments
fbongiovanni29 commented 2023-08-24 01:58:44 +00:00 (Migrated from gitea.com)
Copy Link

I'm standing up other services such as ArgoCD/Backstage/etc. that use redis/postgres. I'd like to share a postgres instance and redis instance between them hosted in GCP. How can I configure the gitea helm chart to do this?

It looks like it should be possible, but seems tricky.

I'm standing up other services such as ArgoCD/Backstage/etc. that use redis/postgres. I'd like to share a postgres instance and redis instance between them hosted in GCP. How can I configure the gitea helm chart to do this? It looks like it should be possible, but seems tricky.
pat-s commented 2023-08-24 07:36:13 +00:00 (Migrated from gitea.com)
Copy Link

I don't understand the request yet - where is the relation to Gitea? It sounds like you're asking how to connect external apps to redis/postgres.

I don't understand the request yet - where is the relation to Gitea? It sounds like you're asking how to connect external apps to redis/postgres.
fbongiovanni29 commented 2023-08-24 21:16:14 +00:00 (Migrated from gitea.com)
Copy Link

Sorry, I realize that was unclear. All I really want to know is how to configure the helm chart to use an external postgres & redis instance rather than the ones provided by the helm chart.

Sorry, I realize that was unclear. All I really want to know is how to configure the helm chart to use an external postgres & redis instance rather than the ones provided by the helm chart.
pat-s commented 2023-08-26 11:02:45 +00:00 (Migrated from gitea.com)
Copy Link

You need to set up the config vars for the respective service as outlined in the cheat sheet, e.g. for Databases: https://docs.gitea.com/next/administration/config-cheat-sheet#database-database.

The same for every other service. At the same time, you should disable the helm-chart dependency for the respective service so you don't deploy unused pods.

This is not specific to the helm chart and a basic administration task for various external tools, which is probably why it hasn't been explicitly documented so far.

You need to set up the config vars for the respective service as outlined in the cheat sheet, e.g. for Databases: https://docs.gitea.com/next/administration/config-cheat-sheet#database-database. The same for every other service. At the same time, you should disable the helm-chart dependency for the respective service so you don't deploy unused pods. This is not specific to the helm chart and a basic administration task for various external tools, which is probably why it hasn't been explicitly documented so far.
smolinari commented 2023-10-08 07:10:43 +00:00 (Migrated from gitea.com)
Copy Link

I'm also finding the docs a bit confusing....

Before upgrading to the newest major version, I had my Postgres db credentials being pulled from secrets in the gitea.additionalConfigFromEnvs (and still are after the renaming that was required to upgrade). Now I'm reading they can (should?) be put into the gitea.config property? What is correct? What is best? Does it matter?

It would be nice if the Redis config were documented on how to "key in" the config values into the chart, much like the database section does, especially because it's not totally clear where or what needs to use redis. After reading a good bit, I found there is the cache, the queue and sessions. They all have to be manually set, correct? Or can I just hook up the redis instance and Gitea would know to use it, where it needs it?

Can you agree this might need a bit better clarification in the docs? As I see it, the goal of a Helm charts is to ease the installation of an application, no matter what the infrastructure decisions are.

That said, I'm using a mail server called Mailu. It has a ton of config too. Yet, I feel their helm chart also handles the choice between external databases or self-installed ones fairly elegantly. https://github.com/Mailu/helm-charts/blob/master/mailu/values.yaml

Maybe it can offer some food for thought on ways to possibly improve this chart? 😀

Scott

I'm also finding the docs a bit confusing.... Before upgrading to the newest major version, I had my Postgres db credentials being pulled from secrets in the `gitea.additionalConfigFromEnvs` (and still are after the renaming that was required to upgrade). Now I'm reading they can (should?) be put into the `gitea.config` property? What is correct? What is best? Does it matter? It would be nice if the Redis config were documented on how to "key in" the config values into the chart, much like the database section does, especially because it's not totally clear where or what needs to use redis. After reading a good bit, I found there is the cache, the queue and sessions. They all have to be manually set, correct? Or can I just hook up the redis instance and Gitea would know to use it, where it needs it? Can you agree this might need a bit better clarification in the docs? As I see it, the goal of a Helm charts is to ease the installation of an application, no matter what the infrastructure decisions are. That said, I'm using a mail server called Mailu. It has a ton of config too. Yet, I feel their helm chart also handles the choice between external databases or self-installed ones fairly elegantly. https://github.com/Mailu/helm-charts/blob/master/mailu/values.yaml Maybe it can offer some food for thought on ways to possibly improve this chart? 😀 Scott
pat-s commented 2023-10-09 15:37:44 +00:00 (Migrated from gitea.com)
Copy Link

Before upgrading to the newest major version, I had my Postgres db credentials being pulled from secrets in the gitea.additionalConfigFromEnvs (and still are after the renaming that was required to upgrade). Now I'm reading they can (should?) be put into the gitea.config property? What is correct? What is best? Does it matter?

It's just a secret. It doesn't matter how you import it as long as it's secured/encrypted in some way.

They all have to be manually set, correct? Or can I just hook up the redis instance and Gitea would know to use it, where it needs it?

You only need to configure it manually if you roll your own external redis as the chart can't guess the connection information.

Can you agree this might need a bit better clarification in the docs?

What might need better clarification? That session, cache and queue exists and need to be configured when using an external instance?
This has been like this forever and is covered by "how to to configure gitea with external apps" in the official documentation.
We could duplicate it again here but lately I feel that most people only look once in the the helm chart README and expect to find every detail there without consulting the official documentation.
The facts above don't really relate to the helm installation method specifically but to configuring Gitea in general.

That said, I'm using a mail server called Mailu. It has a ton of config too. Yet, I feel their helm chart also handles the choice between external databases or self-installed ones fairly elegantly. https://github.com/Mailu/helm-charts/blob/master/mailu/values.yaml

What exactly do you refer to? "external" and "self-installed" are actually the same in this context.

I think we're always open to suggestions and we'll discuss them here/internally but we can't guarantee to implement all of them.

> Before upgrading to the newest major version, I had my Postgres db credentials being pulled from secrets in the gitea.additionalConfigFromEnvs (and still are after the renaming that was required to upgrade). Now I'm reading they can (should?) be put into the gitea.config property? What is correct? What is best? Does it matter? It's just a secret. It doesn't matter how you import it as long as it's secured/encrypted in some way. > They all have to be manually set, correct? Or can I just hook up the redis instance and Gitea would know to use it, where it needs it? You only need to configure it manually if you roll your own external redis as the chart can't guess the connection information. > Can you agree this might need a bit better clarification in the docs? What might need better clarification? That `session`, `cache` and `queue` exists and need to be configured when using an external instance? This has been like this forever and is covered by "how to to configure gitea with external apps" in the official documentation. We could duplicate it again here but lately I feel that most people only look once in the the helm chart README and expect to find every detail there without consulting the official documentation. The facts above don't really relate to the helm installation method specifically but to configuring Gitea in general. > That said, I'm using a mail server called Mailu. It has a ton of config too. Yet, I feel their helm chart also handles the choice between external databases or self-installed ones fairly elegantly. https://github.com/Mailu/helm-charts/blob/master/mailu/values.yaml What exactly do you refer to? "external" and "self-installed" are actually the same in this context. I think we're always open to suggestions and we'll discuss them here/internally but we can't guarantee to implement all of them.
smolinari commented 2023-10-09 16:14:01 +00:00 (Migrated from gitea.com)
Copy Link

It's just a secret. It doesn't matter how you import it as long as it's secured/encrypted in some way.

My question was, which part of the chart should the secrets be added? gitea.additionalConfigFromEnvs or gitea.config. Or does it not matter?

What might need better clarification? That session, cache and queue exists and need to be configured when using an external instance?

Yes

This has been like this forever

Yes, but people new to Gitea and installing it via this chart won't be in the know to go to the docs to understand how to set the charts values for an external Redis instance.

Once more, the purpose of a Helm chart is to make the installation of an application simple(r) in k8s. Expecting the user of the chart to go to the docs to find answers on the k8s installation "because this has been like this forever" is a poor expectation that will fail practically every time. Either the docs for the Helm chart need to properly point to the regular docs as the reference to getting something done or the chart does the work for the user. Neither is happening currently for Redis. The database docs are a bit better, but only a little.

What exactly do you refer to? "external" and "self-installed" are actually the same in this context.

"External" is a database instance already installed by the user. "Self-installed" is an instance installed by the chart. Maybe "chart-installed" would have been a better choice of wording, instead of "self-installed".

I think we're always open to suggestions and we'll discuss them here/internally but we can't guarantee to implement all of them.

I can't expect anything more. I just hope you can agree the chart or the chart's docs can be improved in general. Thanks.

Scott

> It's just a secret. It doesn't matter how you import it as long as it's secured/encrypted in some way. My question was, which part of the chart should the secrets be added? `gitea.additionalConfigFromEnvs` or `gitea.config`. Or does it not matter? > What might need better clarification? That session, cache and queue exists and need to be configured when using an external instance? Yes > This has been like this forever Yes, but people new to Gitea and installing it via this chart won't be in the know to go to the docs to understand how to set the charts values for an external Redis instance. Once more, the purpose of a Helm chart is to make the installation of an application simple(r) in k8s. Expecting the user of the chart to go to the docs to find answers on the k8s installation "because this has been like this forever" is a poor expectation that will fail practically every time. Either the docs for the Helm chart need to properly point to the regular docs as the reference to getting something done or the chart does the work for the user. Neither is happening currently for Redis. The database docs are a bit better, but only a little. > What exactly do you refer to? "external" and "self-installed" are actually the same in this context. "External" is a database instance already installed by the user. "Self-installed" is an instance installed by the chart. Maybe "chart-installed" would have been a better choice of wording, instead of "self-installed". > I think we're always open to suggestions and we'll discuss them here/internally but we can't guarantee to implement all of them. I can't expect anything more. I just hope you can agree the chart or the chart's docs can be improved in general. Thanks. Scott
pat-s commented 2023-10-09 17:56:05 +00:00 (Migrated from gitea.com)
Copy Link

Or does it not matter?

It does not matter.

Yes, but people new to Gitea and installing it via this chart won't be in the know to go to the docs to understand how to set the charts values for an external Redis instance.

Hmm. I'd argue that if you have one and want to configure any service against it, reading the docs of the respective app is a must.
I actually think that people should read the docs more often/in greater detail before just doing a "quick setup", especially for such tasks as the above one.
This is surely a bit of a subjective topic here and many people will have a different opinion about it.
Yet, seeing other issues opened in the last weeks, I got a bit the feeling that people like to spend rather time writing/opening issues and complaining about defaults which don't meet their needs instead of reading the docs and adapting the config/install to their needs.
There is a reason for a central place WRT to documentation like the above. Otherwise we would have to maintain it for every single installation option in multiple places.
If you extend this idea, you would need to document every single config value down to the git config and tell users what and where to set the value (again, this is a bit extreme but I think you get the point: what to include and what not?)

"External" is a database instance already installed by the user. "Self-installed" is an instance installed by the chart. Maybe "chart-installed" would have been a better choice of wording, instead of "self-installed".

The chart configures a working install. If external apps should be used, one needs to consult the official documentation and check how to establish a connection. And it's literally just one connection string and this is the same as for every other app out there (no matter if connecting to postgres, redis, minio, you name it).
As an alternative, one can even check the app.ini of a dummy/test install and check the values there.

Once more, the purpose of a Helm chart is to make the installation of an application simple(r) in k8s. Expecting the user of the chart to go to the docs to find answers on the k8s installation "because this has been like this forever" is a poor expectation that will fail practically every time. Either the docs for the Helm chart need to properly point to the regular docs as the reference to getting something done or the chart does the work for the user. Neither is happening currently for Redis. The database docs are a bit better, but only a little.

I am not sharing your view here. The chart already configures a working installation. If one decides to use external applications, they need to consult the official documentation at the latest at this point.
Gitea can be configured in so many ways, it's impossible to list and describe all possible options.
I am a somewhat desperate about this lately as I got the impression that we got some issues around "why isn't my very specific XYZ config described to the latest detail in the README?"
If such attempts fail because of a missing link to the redis configuration options within the official documentation, then I am out of words at this point...
Not saying that we can't put a link there but you might also notice that I am putting a lot of time into explaining this by replying so extensively.

I am closing here as we went a bit off-topic and me a bit emotional. Guess I should take a bit of a break from answering issues 🙃 Thanks for your replies/suggestions, nothing personal - just me being a bit upset with the latest requests that came up here.

> Or does it not matter? It does not matter. > Yes, but people new to Gitea and installing it via this chart won't be in the know to go to the docs to understand how to set the charts values for an external Redis instance. Hmm. I'd argue that if you have one and want to configure any service against it, reading the docs of the respective app is a must. I actually think that people should read the docs more often/in greater detail before just doing a "quick setup", especially for such tasks as the above one. This is surely a bit of a subjective topic here and many people will have a different opinion about it. Yet, seeing other issues opened in the last weeks, I got a bit the feeling that people like to spend rather time writing/opening issues and complaining about defaults which don't meet their needs instead of reading the docs and adapting the config/install to their needs. There is a reason for a central place WRT to documentation like the above. Otherwise we would have to maintain it for every single installation option in multiple places. If you extend this idea, you would need to document every single config value down to the git config and tell users what and where to set the value (again, this is a bit extreme but I think you get the point: what to include and what not?) > "External" is a database instance already installed by the user. "Self-installed" is an instance installed by the chart. Maybe "chart-installed" would have been a better choice of wording, instead of "self-installed". The chart configures a working install. If external apps should be used, one needs to consult the official documentation and check how to establish a connection. And it's literally just one connection string and this is the same as for every other app out there (no matter if connecting to postgres, redis, minio, you name it). As an alternative, one can even check the `app.ini` of a dummy/test install and check the values there. > Once more, the purpose of a Helm chart is to make the installation of an application simple(r) in k8s. Expecting the user of the chart to go to the docs to find answers on the k8s installation "because this has been like this forever" is a poor expectation that will fail practically every time. Either the docs for the Helm chart need to properly point to the regular docs as the reference to getting something done or the chart does the work for the user. Neither is happening currently for Redis. The database docs are a bit better, but only a little. I am not sharing your view here. The chart already configures a working installation. If one decides to use external applications, they *need* to consult the official documentation **at the latest** at this point. Gitea can be configured in so many ways, it's impossible to list and describe all possible options. I am a somewhat desperate about this lately as I got the impression that we got some issues around "why isn't my very specific XYZ config described to the latest detail in the README?" If such attempts fail because of a missing link to the redis configuration options within the official documentation, then I am out of words at this point... Not saying that we can't put a link there but you might also notice that I am putting a lot of time into explaining this by replying so extensively. I am closing here as we went a bit off-topic and me a bit emotional. Guess I should take a bit of a break from answering issues 🙃 Thanks for your replies/suggestions, nothing personal - just me being a bit upset with the latest requests that came up here.
smolinari commented 2023-10-10 03:52:15 +00:00 (Migrated from gitea.com)
Copy Link

@pat-s - You are unfortunately putting the users of the chart in the "being too lazy to read docs" category and that's not what I'm saying. The point of the users coming here and "complaining" isn't because they don't read the docs, it's because they don't know what in particular they should read in the docs. Are they supposed to read all of the docs to know what is missing? How should they know to hit three different section of the cheat sheet to get all the info they need to setup Gitea with an external Redis? They simply won't. So, they come here and make their case for better chart docs.

Or, the chart should offer a direct option to enter things in a standard way for an external Redis.

On a side note: If I understood the Gitea docs correctly, if there isn't a Redis set up (properly), Gitea should still work. This chart doesn't allow for that. Gitea doesn't work, when the Redis instance section is set to redis.enabled: false

This happens (in my installation):

2023/10/10 03:37:53 ...les/queue/manager.go:108:]() [E] Failed to create queue "mail": dial tcp: lookup gitpoint-redis-cluster-headless.gitpoint.svc.cluster.local: no such host

So, I'd even consider the whole Redis setup a bug.

I'm not understanding your hand-wavy attitude. This chart needs improvement for sure. Try installing Gitea with it and put yourself in the user's shoes of being ignorant to Gitea's Redis needs and think about the wall the user hits, when the chart doesn't work, because not everything is set up properly, when (if my understanding of the Gitea docs is correct) the docs say it should run anyway. Then not knowing where to look in the docs for a proper Redis config, because it is spread over 3 different sections of a cheat sheet.

The chart docs should, at a minimum, refer the user to the three sections of the cheat sheet.

In the cache section, it should have

Many cloud providers offer a managed redis service, which can be used instead of the built-in redis-cluster. If you use an external provider or your own Redis instance, refer to the cheat sheet for the exact config values necessary.

I'd also add a minimum example config entry.

And there also needs to be two new sections for queue and session config exactly like the above.

The better solution is the chart just has an external redis credentials section, like in the example chart I mentioned in my first post.

If I can get my installation working, I'll be happy to offer a PR on the chart's docs, since you seem to be happy with the current poor situation. You can correct my PR, if it is technically incorrect.

Scott

@pat-s - You are unfortunately putting the users of the chart in the "being too lazy to read docs" category and that's not what I'm saying. The point of the users coming here and "complaining" isn't because they don't read the docs, it's because they don't know what in particular they should read in the docs. Are they supposed to read all of the docs to know what is missing? How should they know to hit three different section of the cheat sheet to get all the info they need to setup Gitea with an external Redis? They simply won't. So, they come here and make their case for better chart docs. Or, the chart should offer a direct option to enter things in a standard way for an external Redis. On a side note: If I understood the Gitea docs correctly, if there isn't a Redis set up (properly), Gitea should still work. This chart doesn't allow for that. Gitea doesn't work, when the Redis instance section is set to `redis.enabled: false` This happens (in my installation): ``` 2023/10/10 03:37:53 ...les/queue/manager.go:108:]() [E] Failed to create queue "mail": dial tcp: lookup gitpoint-redis-cluster-headless.gitpoint.svc.cluster.local: no such host ``` So, I'd even consider the whole Redis setup a bug. I'm not understanding your hand-wavy attitude. This chart needs improvement for sure. Try installing Gitea with it and put yourself in the user's shoes of being ignorant to Gitea's Redis needs and think about the wall the user hits, when the chart doesn't work, because not everything is set up properly, when (if my understanding of the Gitea docs is correct) the docs say it should run anyway. Then not knowing where to look in the docs for a proper Redis config, because it is spread over 3 different sections of a cheat sheet. The chart docs should, at a minimum, refer the user to the three sections of the cheat sheet. In the cache section, it should have > Many cloud providers offer a managed redis service, which can be used instead of the built-in redis-cluster. **If you use an external provider or your own Redis instance, refer to the cheat sheet for the exact config values necessary.** I'd also add a minimum example config entry. And there also needs to be two new sections for queue and session config exactly like the above. The better solution is the chart just has an external redis credentials section, like in the example chart I mentioned in my first post. If I can get my installation working, I'll be happy to offer a PR on the chart's docs, since you seem to be happy with the current poor situation. You can correct my PR, if it is technically incorrect. Scott
kha7iq commented 2023-10-17 11:53:51 +00:00 (Migrated from gitea.com)
Copy Link

I run into same issue when wanted to use external redis instead of the one provided. I did read the docs and after trying multiple configs i got it to work without redis. The point @smolinari is making that there are improvements which can be made to the chart for such scenarios and we are happy to contribute.
Considering a fairly new user of gittea some guidance in this regard is required to make such improvements.

If you disable redis from values.yaml file the chart still includes it as provider, by default the values should be changed to memory for sessions config.
1
To reproduce just disable redis and render the template of chart.

helm template gitea . | grep -i redis
    PROVIDER=redis

config.yaml

session: |-
    PROVIDER=redis
    PROVIDER_CONFIG=

This results in following error when the pod starts

2023/10/17 10:33:48 cmd/web.go:212:func1() [F] PANIC: dial tcp 127.0.0.1:6379: connect: connection refused

To fix this, if redis is disabled and no external host is configured the following should be the default values

  session: |-
    PROVIDER=memory
    PROVIDER_CONFIG=data/sessions

A block of external redis host can be added to values.yaml file for such scenarios for both database and redis which will make this very easy for the users.
i.e from the link

externalRedis:
  enabled: false
  host: ""
  port: 6379
I run into same issue when wanted to use external redis instead of the one provided. I did read the docs and after trying multiple configs i got it to work without redis. The point @smolinari is making that there are improvements which can be made to the chart for such scenarios and we are happy to contribute. Considering a fairly new user of gittea some guidance in this regard is required to make such improvements. If you disable redis from values.yaml file the chart still includes it as provider, by default the values should be changed to memory for sessions config. 1 To reproduce just disable redis and render the template of chart. ``` helm template gitea . | grep -i redis PROVIDER=redis ``` `config.yaml` ```yaml session: |- PROVIDER=redis PROVIDER_CONFIG= ``` This results in following error when the pod starts ```bash 2023/10/17 10:33:48 cmd/web.go:212:func1() [F] PANIC: dial tcp 127.0.0.1:6379: connect: connection refused ``` To fix this, if redis is disabled and no external host is configured the following should be the default values ```yaml session: |- PROVIDER=memory PROVIDER_CONFIG=data/sessions ``` A block of external redis host can be added to `values.yaml` file for such scenarios for both database and redis which will make this very easy for the users. i.e from the link ```yaml externalRedis: enabled: false host: "" port: 6379 ```
pat-s commented 2023-10-17 13:40:41 +00:00 (Migrated from gitea.com)
Copy Link

If you disable redis from values.yaml file the chart still includes it as provider, by default the values should be changed to memory for sessions config.

This is well known and tracked in #356

A block of external redis host can be added to values.yaml file for such scenarios for both database and redis which will make this very easy for the users.
i.e from the link

We won't do this and this won't help. Both sections would aim to modify the same internal gitea settings and just conflict. Besides, there's no need for it as it doesn't matter whether the connection is internal (chart) or external - all it matters is a proper config if things deviate from the default chart config.

> If you disable redis from values.yaml file the chart still includes it as provider, by default the values should be changed to memory for sessions config. This is well known and tracked in #356 > A block of external redis host can be added to values.yaml file for such scenarios for both database and redis which will make this very easy for the users. i.e from the link We won't do this and this won't help. Both sections would aim to modify the same internal gitea settings and just conflict. Besides, there's no need for it as it doesn't matter whether the connection is internal (chart) or external - all it matters is a proper config if things deviate from the default chart config.
kha7iq commented 2023-10-17 13:56:40 +00:00 (Migrated from gitea.com)
Copy Link

We won't do this and this won't help. Both sections would aim to modify the same internal gitea settings and just conflict. Besides, there's no need for it as it doesn't matter whether the connection is internal (chart) or external - all it matters is a proper config if things deviate from the default chart config.

I guess there is no point discussing this further, i genuinely don't understand how it will create conflict when both are trying to change the same gitea settings, there are countless charts i have created and using my self as well where you modify a certain setting based on the arguments in values file.
if enabled do this otherwise do something else

In any case thank you for the response

> We won't do this and this won't help. Both sections would aim to modify the same internal gitea settings and just conflict. Besides, there's no need for it as it doesn't matter whether the connection is internal (chart) or external - all it matters is a proper config if things deviate from the default chart config. > > I guess there is no point discussing this further, i genuinely don't understand how it will create conflict when both are trying to change the same gitea settings, there are countless charts i have created and using my self as well where you modify a certain setting based on the arguments in values file. _if enabled do this otherwise do something else_ In any case thank you for the response
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
has/backport
in progress
invalid
kind/breaking
kind/bug
kind/build
kind/dependency
kind/deployment
kind/docs
kind/enhancement
kind/feature
kind/lint
kind/proposal
kind/question
kind/refactor
kind/security
kind/testing
kind/translation
kind/ui
need/backport
priority/critical
priority/low
priority/maybe
priority/medium
reviewed/duplicate
reviewed/invalid
reviewed/wontfix
skip-changelog
status/blocked
status/needs-feedback
status/needs-reviews
status/wip
upstream/gitea
upstream/other
No Label
kind/question
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: lunny/helm-chart#489
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?