Utilize bjw-s's common Helm library. #13

Merged
konrad merged 41 commits from :new-helm-chart into main 2023-11-07 14:47:24 +00:00
Contributor

Utilizing the library allows users the same configuration that they expected from k8s@home, since that's the library that was used. (#10)

This greatly decreases the development toil as well, as you can see.

I've created two different Ingress objects to decouple the backend from the frontend, so that users can set up one, the other, or both.

I've created this as a draft so that I can get any input you might have, if you want to go this route :)

Todo

  • Update README.md showing users how to add/modify/update values.
Utilizing the library allows users the same configuration that they expected from `k8s@home`, since that's the library that was used. (https://kolaente.dev/vikunja/helm-chart/issues/10) This greatly decreases the development toil as well, as you can see. I've created two different `Ingress` objects to decouple the `backend` from the `frontend`, so that users can set up one, the other, or both. I've created this as a draft so that I can get any input you might have, if you want to go this route :) ## Todo - Update README.md showing users how to add/modify/update values.
perfectra1n added 5 commits 2023-09-29 02:05:30 +00:00
perfectra1n changed title from [DRAFT] Utilize bjw-s's `common` Helm library. to [WIP] Utilize bjw-s's `common` Helm library. 2023-09-29 02:05:45 +00:00
perfectra1n added 1 commit 2023-09-29 02:06:27 +00:00
continuous-integration/drone/pr Build is passing Details
28b3153b6c
change environment variable names
perfectra1n added 1 commit 2023-09-29 04:51:37 +00:00
continuous-integration/drone/pr Build is passing Details
56d5371e30
well this works :)
perfectra1n added 1 commit 2023-09-29 04:52:04 +00:00
continuous-integration/drone/pr Build is passing Details
7224e44db3
oops this too
Author
Contributor

This chart should create all the resources needed now, just need to do some brain gymnastics of what URLs to set the Frontend/Backend to by default...NodePorts perhaps?

This chart should create all the resources needed now, just need to do some brain gymnastics of what URLs to set the Frontend/Backend to by default...NodePorts perhaps?
Owner

@vlasov-y @xeruf thoughts?

@vlasov-y @xeruf thoughts?
Author
Contributor

I'm essentially trying to mirror what Immich is doing here: https://github.com/immich-app/immich-charts

But of course for Vikunja, and allowing a user to set up:

  1. Backend
  2. Frontend
  3. Both

On top of the optional deployments (Typesense, Redis, PostgreSQL, etc.).

If you guys like where I'm going with this, I can continue on with it from input from you all. If not, no hard feelings either :)

I'm essentially trying to mirror what Immich is doing here: https://github.com/immich-app/immich-charts But of course for Vikunja, and allowing a user to set up: 1. Backend 2. Frontend 3. Both On top of the optional deployments (Typesense, Redis, PostgreSQL, etc.). If you guys like where I'm going with this, I can continue on with it from input from you all. If not, no hard feelings either :)
Author
Contributor

@konrad I can finish this up this weekend if you're still interested in this approach. If not, I'll just keep it on pause :)

@konrad I can finish this up this weekend if you're still interested in this approach. If not, I'll just keep it on pause :)
konrad reviewed 2023-10-04 16:11:26 +00:00
@ -0,0 +1,34 @@
{{- define "vikunja.backend.hardcodedValues" -}}
global:
nameOverride: backend
Owner

Is this a special "backend" or the api service? If it's the api, it should be called api.

(I know there are still parts of Vikunja's documentation where it's called "backend" but I'd like to get rid of that anyway)

Is this a special "backend" or the api service? If it's the api, it should be called api. (I know there are still parts of Vikunja's documentation where it's called "backend" but I'd like to get rid of that anyway)
Author
Contributor

Gotchya, I'll rename that to be api instead. I saw backend in the docs like you said, so I just ran with that.

Gotchya, I'll rename that to be `api` instead. I saw `backend` in the docs like you said, so I just ran with that.
perfectra1n marked this conversation as resolved
@ -13,3 +1,1 @@
{{- toYaml . | nindent 4 }}
{{- end }}
{{- end }}
{{- define "vikunja.serviceAccount.hardcodedValues" -}}
Owner

Is that a Vikunja user or a system user?

Is that a Vikunja user or a system user?
Author
Contributor

It's a Kubernetes "non-human" user, a Kubernetes-specific object.

ServiceAccount objects in Kubernetes serve several purposes within the cluster:

  1. Provide a distinct identity: Service accounts offer a unique identity for application pods, system components, and other entities within the cluster. This identity is useful for authentication and implementing identity-based security policies.

  2. Namespace-bound: Service accounts are bound to a specific namespace, and each namespace has a default service account created upon its creation. This allows for better organization and management of access control within the cluster.

  3. Lightweight and easily managed: Service accounts are defined in the Kubernetes API, making them easy to create and manage for specific tasks.

  4. Authentication and authorization: Service accounts enable pods to authenticate to the Kubernetes API server or external services. They can also be used to implement role-based access control (RBAC) policies, granting specific permissions to pods based on their associated service accounts.

  5. Support for token-based authentication: Service accounts use token-based authentication, which can be automatically mounted as credentials inside pods[2]. This allows processes running in pods to access the Kubernetes API using the service account's identity.

  6. Portability: Service accounts can be created without many constraints and have namespaced names, making them portable across different configurations and complex systems.

It's a Kubernetes "non-human" user, a Kubernetes-specific object. > ServiceAccount objects in Kubernetes serve several purposes within the cluster: > >1. Provide a distinct identity: Service accounts offer a unique identity for application pods, system components, and other entities within the cluster. This identity is useful for authentication and implementing identity-based security policies. > >2. Namespace-bound: Service accounts are bound to a specific namespace, and each namespace has a default service account created upon its creation. This allows for better organization and management of access control within the cluster. > >3. Lightweight and easily managed: Service accounts are defined in the Kubernetes API, making them easy to create and manage for specific tasks. > >4. Authentication and authorization: Service accounts enable pods to authenticate to the Kubernetes API server or external services. They can also be used to implement role-based access control (RBAC) policies, granting specific permissions to pods based on their associated service accounts. > >5. Support for token-based authentication: Service accounts use token-based authentication, which can be automatically mounted as credentials inside pods[2]. This allows processes running in pods to access the Kubernetes API using the service account's identity. > >6. Portability: Service accounts can be created without many constraints and have namespaced names, making them portable across different configurations and complex systems.
Author
Contributor

I went ahead and removed it, the user can add it to each pod as they see fit :)

I went ahead and removed it, the user can add it to each pod as they see fit :)
perfectra1n marked this conversation as resolved
values.yaml Outdated
@ -16,2 +7,2 @@
# If not set and create is true, a name is generated using the fullname template
name: ""
env:
VIKUNJA_REDIS_HOST: '{{ printf "%s-redis-master" .Release.Name }}'
Owner

Is there a reason we're using env here and not the config directly?

We should still be able to configure Vikunja as it can be done currently: https://kolaente.dev/vikunja/helm-chart/src/branch/main/values.yaml#L142

There are things that can't be configured via env like openid providers.

Is there a reason we're using env here and not the config directly? We should still be able to configure Vikunja as it can be done currently: https://kolaente.dev/vikunja/helm-chart/src/branch/main/values.yaml#L142 There are things that can't be configured via env like openid providers.
Author
Contributor

Ah, didn't know that. I thought everything was configurable via env variables (which I've always found easier to manage), but I'll go ahead and use the config instead.

Ah, didn't know that. I thought everything was configurable via `env` variables (which I've always found easier to manage), but I'll go ahead and use the `config` instead.
perfectra1n marked this conversation as resolved
Owner

I like the general idea of making the chart simpler.

What about the upgrade path?

I like the general idea of making the chart simpler. What about the upgrade path?
Author
Contributor

Upgrade path (like upgrading to newer versions of Vikunja) would just require a user to reference a newer version of the image at the top of values.yaml.

Upgrade path (like upgrading to newer versions of Vikunja) would just require a user to reference a newer version of the image at the top of `values.yaml`.
perfectra1n added 1 commit 2023-10-04 17:02:58 +00:00
continuous-integration/drone/pr Build is failing Details
5312dc6a34
change backend to be api
Author
Contributor

I like the general idea of making the chart simpler.

What about the upgrade path?

Not only does it make it simpler, it also allows the user to add/modify the values.yaml to include any of the keys/values you see here (a081de5302/charts/library/common/values.yaml) to add things such as other services, sidecars, etc.

It allows for a ton of customization out of the box, so a user can do whatever they want more or less. Offloading all of the "nuances" a Helm chart would typically have to support (for all of the various weird Cluster configurations) to the common library :)

> I like the general idea of making the chart simpler. > > What about the upgrade path? Not only does it make it simpler, it also allows the user to add/modify the `values.yaml` to include *any* of the keys/values you see here (https://github.com/bjw-s/helm-charts/blob/a081de53024d8328d1ae9ff7e4f6bc500b0f3a29/charts/library/common/values.yaml) to add things such as other services, sidecars, etc. It allows for a ton of customization out of the box, so a user can do whatever they want more or less. Offloading all of the "nuances" a Helm chart would typically have to support (for all of the various weird Cluster configurations) to the `common` library :)
perfectra1n added 1 commit 2023-10-04 17:20:26 +00:00
continuous-integration/drone/pr Build is failing Details
f7731a71f6
remove serviceaccount, user can define if needed
Author
Contributor

Are you phasing out VIKUNJA_API_URL by chance? I don't see it at https://vikunja.io/docs/config-options/, but I still see it in the injector.sh for the Docker container...

Are you phasing out `VIKUNJA_API_URL` by chance? I don't see it at https://vikunja.io/docs/config-options/, but I still see it in the `injector.sh` for the Docker container...
perfectra1n added 2 commits 2023-10-04 23:21:59 +00:00
perfectra1n added 1 commit 2023-10-04 23:26:48 +00:00
continuous-integration/drone/pr Build is failing Details
26c311614d
update comment
Author
Contributor

I'm also trying to add some comments to the values.yaml so that a user is less lost when trying to use the Helm chart. I also intend to update the README.md.

I'm also trying to add some comments to the `values.yaml` so that a user is less lost when trying to use the Helm chart. I also intend to update the README.md.
perfectra1n added 1 commit 2023-10-05 01:54:15 +00:00
Owner

Upgrade path (like upgrading to newer versions of Vikunja) would just require a user to reference a newer version of the image at the top of values.yaml.

I mean upgrading from the current chart to the new one.

Are you phasing out VIKUNJA_API_URL by chance? I don't see it at https://vikunja.io/docs/config-options/, but I still see it in the injector.sh for the Docker container...

No, that's a frontend option. The docs on the page you linked are only for the api.

As long as the api and frontend are reachable under the same domain and port you don't need to set the api url though.

> Upgrade path (like upgrading to newer versions of Vikunja) would just require a user to reference a newer version of the image at the top of `values.yaml`. I mean upgrading from the current chart to the new one. > Are you phasing out `VIKUNJA_API_URL` by chance? I don't see it at https://vikunja.io/docs/config-options/, but I still see it in the `injector.sh` for the Docker container... No, that's a frontend option. The docs on the page you linked are only for the api. As long as the api and frontend are reachable under the same domain and port you don't need to set the api url though.
perfectra1n added 3 commits 2023-10-05 16:30:36 +00:00
perfectra1n added 1 commit 2023-10-05 21:04:27 +00:00
continuous-integration/drone/pr Build is failing Details
763de07818
update README.md
Author
Contributor

I mean upgrading from the current chart to the new one.

I see what you're saying - from a user's perspective, what is updating to this version of the Helm chart like. It will definitely require some changes from a user (so therefore it will be a "breaking" change), but will also make it quite a bit easier to support from our end, while still allowing nearly infinite customization.

No, that's a frontend option.

Understood, it was slightly buried on the Frontend page. I found it now. Thank you!

> I mean upgrading from the current chart to the new one. I see what you're saying - from a user's perspective, what is updating to *this* version of the Helm chart like. It will definitely require some changes from a user (so therefore it will be a "breaking" change), but will also make it quite a bit easier to support from our end, while still allowing nearly infinite customization. > No, that's a frontend option. Understood, it was slightly buried on the Frontend page. I found it now. Thank you!
perfectra1n changed title from [WIP] Utilize bjw-s's `common` Helm library. to Utilize bjw-s's `common` Helm library. 2023-10-05 21:06:36 +00:00
perfectra1n added 1 commit 2023-10-05 21:12:43 +00:00
continuous-integration/drone/pr Build is passing Details
3d576aa0cf
Merge branch 'main' into new-helm-chart
Author
Contributor

@konrad should be ready for another readthrough whenever you're free, I'm confident this now both works and delivers on expectations.

@konrad should be ready for another readthrough whenever you're free, I'm confident this now both works and delivers on expectations.
perfectra1n added 2 commits 2023-10-05 22:31:11 +00:00
konrad requested changes 2023-10-10 16:41:11 +00:00
README.md Outdated
@ -3,3 +3,2 @@
Customizable deployment of frontend and api.
Deploys bitnami's PostgreSQL and Redis as subcharts if you want.
Deployes both frontend and api. Also, you can deploy bitnami's PostgreSQL and Redis as subcharts if you want.
Owner

Typo: Should be "deploys"

Typo: Should be "deploys"
Author
Contributor

oops, thanks for catching that! fat finger

oops, thanks for catching that! fat finger
Author
Contributor
https://kolaente.dev/vikunja/helm-chart/commit/d8500214e98def13755bad78e31e9b2e39404df1
konrad marked this conversation as resolved
README.md Outdated
@ -13,3 +12,2 @@
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
The majority of default values defined in `values.yaml` should be compatible for your deployment. Additionally, if you utilize an Ingress for both the API and Frontend, you will be able to access the frontend out of the box. However, it won't have any default credentials, you will need to **either** enable registration, or execute `/bin/sh` on the API container and run the following command:
Owner

Registration is enabled by default, maybe change this to "you need to create an account before using it, there are no default credentials".

Not sure if we should even leave this in here as it is not specific for the helm deployment.

Registration is enabled by default, maybe change this to "you need to create an account before using it, there are no default credentials". Not sure if we should even leave this in here as it is not specific for the helm deployment.
Author
Contributor

What do you think about this change?:

688a055c36

What do you think about this change?: https://kolaente.dev/vikunja/helm-chart/commit/688a055c369218558392df042f8ee6e16900e0f6
Owner

Looks good!

Looks good!
konrad marked this conversation as resolved
@ -0,0 +28,4 @@
custom: true
spec:
httpGet:
path: /api/v1
Owner

Shouldn't this use /api/v1/info as /api/v1 will usually give an error?

Shouldn't this use `/api/v1/info` as `/api/v1` will usually give an error?
Author
Contributor

LOL, I've gotta say, that explains a lot about my own Vikunja deployment after realizing that /api/v1 returns a 401...

fixed!

LOL, I've gotta say, that explains a lot about my own Vikunja deployment after realizing that `/api/v1` returns a `401`... fixed!
Author
Contributor
https://kolaente.dev/vikunja/helm-chart/commit/61b8892ff0aa802e33c40656e27caa6105b48881
Owner

hehe yeah there's an item in the backlog to add a health endpoint eventually which would also check if the db connection works etc.

hehe yeah there's an item in the backlog to add a `health` endpoint eventually which would also check if the db connection works etc.
konrad marked this conversation as resolved
values.yaml Outdated
@ -163,0 +17,4 @@
######################
# VIKUNJA COMPONENTS #
######################
# You can find the default values
Owner

Doesn't this need a link to the docs with the default config?

Doesn't this need a link to the docs with the default config?
Author
Contributor

fixed

d8500214e9

fixed https://kolaente.dev/vikunja/helm-chart/commit/d8500214e98def13755bad78e31e9b2e39404df1
konrad marked this conversation as resolved
values.yaml Outdated
@ -183,0 +37,4 @@
# proxy-body-size is set to 0 to remove the body limit on file uploads
nginx.ingress.kubernetes.io/proxy-body-size: "0"
hosts:
- host: vikunja.local
Owner

Why vikunja.local?

Why `vikunja.local`?
Author
Contributor

The existing chart has “chart-example.local”, I figured that changing that to “vikunja.local” would be more Vikunja “branded”, if you will, lol.

I can change it back if you would prefer!

The existing chart has “chart-example.local”, I figured that changing that to “vikunja.local” would be more Vikunja “branded”, if you will, lol. I can change it back if you would prefer!
Owner

I'm fine with either but it should be clear that the value is only an example value and should be changed.

I'm fine with either but it should be clear that the value is only an example value and should be changed.
Author
Contributor
https://kolaente.dev/vikunja/helm-chart/commit/7d2f43fee3d21c2a5844ac71bcf54c7da96cf1b9
konrad marked this conversation as resolved
values.yaml Outdated
@ -183,0 +57,4 @@
host: '{{ .Release.Name }}-postgresql'
service:
# Vikunja needs to know the frontend URL for password reset emails.
frontendUrl: http://vikunja.local
Owner

But the default value for this one is the one defined in the ingress, why define it here again?

But the default value for this one is the one defined in the ingress, why define it here again?
Author
Contributor

Fair, forgot to use the ingress value for that variable as well. I went ahead and fixed it. I also included a comment to to the user incase they aren't using an ingress resource (I was even using a Service behind a central Nginx until recently)

fixed!

Fair, forgot to use the `ingress` value for that variable as well. I went ahead and fixed it. I also included a comment to to the user incase they aren't using an `ingress` resource (I was even using a `Service` behind a central Nginx until recently) fixed!
Author
Contributor
https://kolaente.dev/vikunja/helm-chart/commit/9cd4680e707c57d06e718f8d1e6f524408965a32 and https://kolaente.dev/vikunja/helm-chart/commit/c601e5e449523ffb7feb7d35ca72389075769d9c
konrad marked this conversation as resolved
perfectra1n added 4 commits 2023-10-10 22:38:04 +00:00
perfectra1n added 1 commit 2023-10-10 22:41:01 +00:00
konrad reviewed 2023-10-11 08:38:27 +00:00
@ -0,0 +40,4 @@
{{ if and .Values.frontend.ingress.enabled .Values.api.configMaps.config.enabled}}
configMaps:
# The configuration for Vikunja's backend.
Owner

Nitpick, but please use "api" here instead of "backend".

Nitpick, but please use "api" here instead of "backend".
Author
Contributor

Done:
76b209a70c :)

Done: https://kolaente.dev/vikunja/helm-chart/commit/76b209a70c3b73b8bcaeff153e8c5a56a3901975 :)
konrad marked this conversation as resolved
@ -0,0 +59,4 @@
VIKUNJA_TYPESENSE_ENABLED: "true"
{{ end }}
# Logic to decide what the api URL should be
Owner

But it's called "frontend url", why call it "api url" in the comment?

Also what is that value used for? Vikunja itself does not use it.

But it's called "frontend url", why call it "api url" in the comment? Also what is that value used for? Vikunja itself does not use it.
Author
Contributor

Yeah that logic was in the wrong place, that was meant for the Frontend container to "learn" what the API URL was. Fixed:
3ea99647e2

Yeah that logic was in the wrong place, that was meant for the Frontend container to "learn" what the API URL was. Fixed: https://kolaente.dev/vikunja/helm-chart/commit/3ea99647e2b2343762d9fe7ce26def2065f19957
konrad marked this conversation as resolved
perfectra1n added 2 commits 2023-10-11 13:53:11 +00:00
perfectra1n added 1 commit 2023-10-11 13:58:59 +00:00
continuous-integration/drone/pr Build is passing Details
688a055c36
Fix README.md
perfectra1n added 1 commit 2023-10-11 14:05:27 +00:00
continuous-integration/drone/pr Build is passing Details
48c7b05968
change api url `/api` to `/api/v1`
perfectra1n added 1 commit 2023-10-11 14:07:02 +00:00
continuous-integration/drone/pr Build is passing Details
746555db06
add comment about PVC
perfectra1n added 1 commit 2023-10-11 14:12:01 +00:00
continuous-integration/drone/pr Build is passing Details
d406bb50fd
change md heading
perfectra1n added 1 commit 2023-10-21 00:12:24 +00:00
continuous-integration/drone/pr Build is passing Details
915fe85298
add more context
perfectra1n added 1 commit 2023-10-21 00:25:42 +00:00
continuous-integration/drone/pr Build is passing Details
6352bb844c
add more comments about VIKUNJA_API_URL
perfectra1n added 1 commit 2023-10-21 00:28:01 +00:00
continuous-integration/drone/pr Build is passing Details
34b6d620aa
toss this
perfectra1n added 1 commit 2023-10-21 01:00:51 +00:00
continuous-integration/drone/pr Build is passing Details
a3a944482e
this needs to be a string
perfectra1n added 1 commit 2023-10-21 19:37:37 +00:00
Author
Contributor

I've opted to using the env key for the api container, since Helm templating is enabled on the environment variables - so users can provide secretRef to reference an external secret (that could hold the user's PostgreSQL password, etc.).

I've opted to using the `env` key for the `api` container, since Helm templating is enabled on the environment variables - so users can provide `secretRef` to reference an external secret (that could hold the user's PostgreSQL password, etc.).
perfectra1n added 1 commit 2023-10-21 19:44:02 +00:00
continuous-integration/drone/pr Build is passing Details
6cefa2e3d2
this should be moved then
perfectra1n added 1 commit 2023-10-21 23:08:10 +00:00
continuous-integration/drone/pr Build is passing Details
0d72431ad7
these need to be double quoted
perfectra1n added 1 commit 2023-10-21 23:19:50 +00:00
continuous-integration/drone/pr Build is passing Details
e09afb9e25
specify tag as well
Author
Contributor

I've deployed this to my Kubernetes cluster, and two other unlucky victims (friends) have it running in their cluster as well.

I've deployed this to my Kubernetes cluster, and two other unlucky victims (friends) have it running in their cluster as well.
konrad reviewed 2023-10-31 20:07:09 +00:00
README.md Outdated
@ -20,2 +17,3 @@
### Registration (creating users)
### Replicas
You can disable registration (if you do not with to allow others to register on your Vikunja), by providing the following values in your `values.yaml`:
Owner

I don't think this should belong here as it's not specific for the helm deployment.

I don't think this should belong here as it's not specific for the helm deployment.
Author
Contributor

Understood - it was meant to be more of an example of how you can utilize the values of the Helm deployment to create the config.yml and make changes. Would it be adequate to perhaps rename the section to "Example of how to create config.yml" and move it to the bottom of the README.md?

Understood - it was meant to be more of an example of how you can utilize the `values` of the Helm deployment to create the `config.yml` and make changes. Would it be adequate to perhaps rename the section to "Example of how to create `config.yml`" and move it to the bottom of the README.md?
Author
Contributor

Renamed the section, and bumped the "modification" examples to the bottom of the README.md in order to highlight how to use a pre-existing PVC. Let me know if you find that to be adequate!

ce56e07518

Renamed the section, and bumped the "modification" examples to the bottom of the README.md in order to highlight how to use a pre-existing PVC. Let me know if you find that to be adequate! https://kolaente.dev/vikunja/helm-chart/commit/ce56e07518e9187f2f406a80c94dc8fddca53a87
Owner

Renaming is great!

Renaming is great!
@ -0,0 +16,4 @@
env:
{{- if .Values.api.ingress.main.enabled }}
VIKUNJA_API_URL: "http://{{ index .Values.api.ingress.main.hosts 0 "host" }}{{ index .Values.api.ingress.main.hosts 0 "path" }}"
Owner

What if the api ingress is using https?

What if the api ingress is using https?
Author
Contributor

By default, ingress-nginx redirects HTTP to HTTPS and the annotation nginx.ingress.kubernetes.io/force-ssl-redirect: "true" can be used with other Kubernetes Ingress objects to redirect HTTP to HTTPS. It's "normal" in the deployments I've created to have to create that annotation on the Ingress if I've required that redirection (or the other way around :))

By default, `ingress-nginx` redirects HTTP to HTTPS and the annotation `nginx.ingress.kubernetes.io/force-ssl-redirect: "true"` can be used with other Kubernetes Ingress objects to redirect HTTP to HTTPS. It's "normal" in the deployments I've created to have to create that annotation on the Ingress if I've required that redirection (or the other way around :))
perfectra1n added 1 commit 2023-11-02 19:34:50 +00:00
continuous-integration/drone/pr Build is passing Details
ce56e07518
Move README.md components around
konrad approved these changes 2023-11-07 14:46:47 +00:00
konrad left a comment
Owner

Thank you very much for the effort!

Thank you very much for the effort!
konrad merged commit 62112e8df0 into main 2023-11-07 14:47:24 +00:00
Sign in to join this conversation.
No reviewers
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: vikunja/helm-chart#13
No description provided.