Add job template to deploy search

[abbottmg]

This creates a simple job template to fire off when deploying elasticsearch, e.g. as part of upgrading to 4.2.0 and beyond.

[abbottmg]

This addresses #87.

[hardillb]

I ran the command this job runs manually after enabling elastic search and it all worked as expected, I vote to get this merged.

[renchap]

If I understand correctly, this will launch an ES re-index after each chart install/upgrade.

This is a bad idea as reindexing is an heavy task and has impact to the cluster. It starts by dropping the indexes, then re-create them, so search results are non-existing and/or wrong until it finished.

Re-indexes should be launched only when needed (a new index is created, or an existing index has an updated schema), and this is nothing in Mastodon to know if this is the case after an update.

I see how this could be useful and will see if we can add a command that launches a re-index only if needed, but for now this should not be merged.

[abbottmg]

The intended use case is to deploy once with this enabled and then disable it before future chart deployments. This is a pattern we already use for other one-time jobs.

[renchap]

The intended use case is to deploy once with this enabled and then disable it before future chart deployments. This is a pattern we already use for other one-time jobs.

I am not sure I understand how this works. How do you disable for future deployments?

[abbottmg]

When you want to deploy search, you pass --set 'matsodon.deploySearch.enabled=true' at the command line, which overrides the setting in values.yaml for that single run.

You can also change that setting to true within your values file, run helm upgrade once, then change it back to false before your next deploy.

[grrywlsn]

Is the intention that it runs once, on initial setup, but then not again on future helm upgrades?

In which case, wouldn't the post-install helm hook be a better fit for what you're trying to do?

Having to change values (especially ones going against the default) to achieve the behaviour feels like an anti-pattern imo.

[hardillb]

The intention was to allow the simple enabling of Elastic Search at the point of an upgrade after an initial install without ES enabled (as discussed in #87)

So the question becomes:

• Should this be something the user needs to do as part of the upgrade (e.g. include the --set option mentioned)
• Or a manual task after that is well documented and easy to find (since the docs linked to in the values.yml currently 404)

[abbottmg]

The intention is [edit: as hardillb noted while I wrote this!] for pre-4.2 installations to run this on upgrade. IIRC a server installed post 4.2 with elasticsearch already working wouldn't need to run this command, but my memory's rusty about that.

In either case, this is technically a post-install hook, as well as a post-upgrade hook. Users may leave this feature enabled across multiple upgrades; they will simply have their databases re-indexed which, as @renchap pointed out yesterday, is heavy work to repeat needlessly.

We can compare and contrast this with job-db-migrate, which also runs in an upgrade hook and so runs every time the chart is upgraded--and can slow down or block deployment, because it requires the database containers to be accessible, even if we're not actually making any changes to the db schema.

We decide to run it every time because the best way to detect whether the work is necessary is to run the rake command anyway. I would definitely love to know if there's an easy way to detect whether ES needs indexing, but I did not come across one as I worked on this implementation. I believe the one method I tried was happy to declare my initial, empty index was correct and up-to-date 😅

[abbottmg]

I've rebased this work onto main. A hooks stanza has since been added so I plan to move the new keys under that heading as soon as able