vikunja/helm-chart
2
2
Fork 5
Code Issues 7 Pull Requests 1 Packages Projects Releases 1 Wiki Activity

Simplify defaults and link more external documentation #12

Merged
konrad merged 2 commits from xeruf/helm-chart:defaults into main 2023-09-29 17:17:07 +00:00
Conversation 1 Commits 2 Files Changed 2 +13 -7
1 changed files with 13 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit 9ae282a684 - Show all commits

20
README.md
View File

@ -14,6 +14,8 @@ Deploys bitnami's PostgreSQL and Redis as subcharts if you want.
Define ingress settings according to your controller (for both API and Frontend) to access the application.
You can set all Vikunja API options as yaml under `api.config`: https://vikunja.io/docs/config-options
konrad marked this conversation as resolved
konrad commented 2023-09-27 15:42:29 +00:00
Review
Copy Link

Can you leave the example?

Can you leave the example?
xeruf commented 2023-09-28 10:59:45 +00:00
Review
Copy Link

I don't really find the example helpful because there is no context.
I would rather point to the values.yaml

I don't really find the example helpful because there is no context. I would rather point to the values.yaml
konrad commented 2023-09-29 17:16:17 +00:00
Review
Copy Link

Makes sense.

Makes sense.
See [values.yaml](./values.yaml#L140) for examples.
## Advanced features
### Replicas
@ -21,7 +23,7 @@ You can set all Vikunja API options as yaml under `api.config`: https://vikunja.
Both Frontend and API can be configured to have replicas including autoscaling.
When replicating the API, make sure to set up the redis cache as well
by setting `api.config.keyvalue.type` to `redis`,
configuring the redis subchart (see [values.yaml](./values.yaml))
configuring the redis subchart (see [values.yaml](./values.yaml#L280))
and the connection to Vikunja:
https://vikunja.io/docs/config-options/#redis
@ -31,7 +33,8 @@ Sometimes you have to deploy some cloud-specific resources that are not a part o
You have to either create an extra chart for that, or manage them with other tools (kustomize, plain manifests etc.).
That is painful. We have a solution. If you want to create anything that is not present in the chart, *just add it in raw*!
Let's say, you are hosted in [GKE](https://cloud.google.com/kubernetes-engine) and want to use Google-managed TLS certificates.
Let's say, you are hosted in [GKE](https://cloud.google.com/kubernetes-engine)
and want to use Google-managed TLS certificates.
In order to do that, you have to create a ManagedCertificate resource:
```yaml
@ -56,7 +59,9 @@ raw:
- example.com
```
Or, let's say, you have decided to use Google SQL database instead of self-hosted, and placed credentials in Google Secret Manager. You plan to use [ExternalSecrets](https://external-secrets.io/v0.7.2/) to get that credentials. These can be easily integrated as well.
Or, let's say, you have decided to use Google SQL database instead of self-hosted, and placed credentials in Google Secret Manager.
You plan to use [ExternalSecrets](https://external-secrets.io/v0.7.2/) to store the credentials.
These can be easily integrated as well.
```yaml
# Disable embedded database
@ -121,8 +126,7 @@ Enjoy!
### Use an existing file volume claim
In the `values.yaml` file, you can configure wether to create the Persistent Volume Claim or use an existing one:
In the `values.yaml` file, you can configure whether to create the Persistent Volume Claim or use an existing one:
```yaml
# Specifies whether a PVC should be created
@ -132,11 +136,13 @@ In the `values.yaml` file, you can configure wether to create the Persistent Vol
name: ""
```
This is helpful when migrating from a different k8s chart and want to re-use the existing volume or if you need more control over how the volume is created.
This is helpful when migrating from a different k8s chart and to re-use the existing volume
xeruf marked this conversation as resolved Outdated
konrad commented 2023-09-27 15:43:56 +00:00
Outdated
Review
Copy Link

Suggestion:

-These steps are automatically performed on a git tag. 
+These steps are automatically performed when a version is tagged and pushed in the repo.
Suggestion: ```diff -These steps are automatically performed on a git tag. +These steps are automatically performed when a version is tagged and pushed in the repo. ```
or if you need more control over how the volume is created.
## Publishing
These steps are automatically performed on a git tag.
The following steps are automatically performed when a git tag for a new version is pushed to the repository.
They are only listed here for reference.
1. Pull all dependencies before packaging.