Error generating template when disabling postgres / redis / elasticsearch

[chrisk-tbot]

Background

When utilizing a cloud provider for data stores (eg: AWS rds for postgres, elasticcache for redis, etc), it is a very reasonable use case to disable all three of the bitnami charts specified in the dependencies. When this happens, the following bitnami common library chart is not included. This will cause issues when the mastodon chart code refers to common.names.fullname (which is only defined in the bitnami common library).

Steps to reproduce

• clone charts repo
• fill in basic values boilerplate for secrets
• disable postgres, redis, and elasticsearch
• generate template

Error received:

Error: template: mastodon/templates/secret-smtp.yaml:5:29: executing "mastodon/templates/secret-smtp.yaml" at <include "common.names.fullname" .>: error calling include: template: no template "common.names.fullname" associated with template "gotpl"

Possible resolution?

• use mastodon.fullname instead (not certain how these would differ)
• include the bitnami common library chart in some toplevel way such that disabling the dependencies doesn't preclude its inclusion

Final note

I am happy to open a PR with one of the above solutions, but lack a bit of the context necessary to decide which is the best choice. Apologies, I'm not terribly familiar with helm templating so some of this code is Greek to me. Cheers

[chrisk-tbot]

cc/ @roobre @deepy (tagging y'all since your commits included the reference to that common.names.fullname)

thanks!

[deepy]

It's been a hot minute since I last did anything with the chart, but common.names.fullname seems somewhat useful but I don't know if it's enough to justify adding another subchart

https://github.com/bitnami/charts/blob/da68be8e951225133c7dfb572d5101ca3d61c5ae/bitnami/common/templates/_names.tpl#L21-L37

But personally I've mostly given up on this chart, it's almost aggressively neglected and I no longer have the time or energy that's required to get pull requests merged

[chrisk-tbot]

@deepy oof thanks for that honest feedback. would you recommend the bitnami one?

[ajguyot]

@chrisk-tbot I migrated from this chart to the bitnami one early last year. The Bitnami chart was a missing some features at the time, but was more standardized (especially if you've worked with Bitnami charts before) and generally far easier to work with if you do need to make any changes to it. I added a few features myself when I switched to it, and since then there have been multiple other contributors that have continued to add to it. It's a lot more alive than this chart is.

The last big missing feature when I last upgraded my instance ~6 months ago was the tootctl media cron jobs, but yesterday when I upgraded to get the 4.2.5 security patch, I found that someone had added those jobs in to. With that, I think there's no question that the Bitnami chart is the way to go.

Lastly, Bitnami actually locks the chart to full versions rather than just minor versions, so you can more carefully manage your upgrades. I upgraded ~6 times yesterday because I was nervous about jumping many missed versions at once, and every upgrade was smooth, including the big db migration between 4.1 and 4.2. Bitnami's process for updating to new image versions is also automated, so the new security patch 4.2.5 that was released yesterday is already available. This chart seems to only be updated manually, so it's often weeks behind the latest patch when there's a bump to the minor version.

(I don't work for Bitnami or anything lol, I just was very frustrated by this chart when I was using it and have been a whole lot happier since switching. Came here out of curiosity to see if this chart was upgraded to 4.2.5 yet and figured I'd give my 2 cents in case it's helpful.)

[chrisk-tbot]

@ajguyot thanks so much for that thorough explanation! Certainly sounds like the way to go. Appreciate you sharing your experience and candid evaluation. Will definitely switch over to using that.

Cheers, super helpful indeed

[deepy]

I've had a quick look at the bitnami chart and packaging. And at a glance it looks good, but they seem to have issues with existingSecrets and seem incompatible with GitOps
And unless something has changed in mastodon, you should not run the scheduler queue in multiple sidekiq instances and the bitnami chart does not take that into account

So unless you want to use GitOps, external secrets, or scale up sidekiq, then the chart looks fine