Enabling Elastic Search after initial Install

[hardillb]

With the upcoming Search changes due in version 4.2.0 I started to look at what is needed to enable Elastic Search on my instance. (I had been running without Elastic Search as it is a single user instance)

Looking at the values.yml I find the following:

chart/values.yaml

Lines 235 to 246 in 4b6fd9f

	# -- https://github.com/bitnami/charts/tree/master/bitnami/elasticsearch#parameters
	elasticsearch:
	# `false` will disable full-text search
	#
	# if you enable ES after the initial install, you will need to manually run
	# RAILS_ENV=production bundle exec rake chewy:sync
	# (https://docs.joinmastodon.org/admin/optional/elasticsearch/)
	# @ignored
	enabled: true
	# @ignored
	image:
	tag: 7

It is not clear where/how to run the command mentioned and the link now 404's (I assume the new version is here https://docs.joinmastodon.org/admin/optional/elasticsearch/)

Can you

1. confirm how the command should be run. I expect something like

   kubectl -n mastodon exec -it mastodon-web-75b84997c-s4lfq -- RAILS_ENV=production bundle exec rake chewy:sync
   

2. That this is still valid for version 4.2.0?
3. Update the URL in the comment

Thanks

[abbottmg]

I wrote a Job resource that looks a lot like the existing job-db-migrate but with the relevant tootctl command and toggles for resetting chewy. I'll port that template down to the mastodon chart and post a branch for you to use later tonight (or by EOD Monday...).

[abbottmg]

@hardillb Take a look at #95. When upgrading to 4.2.0 the resetChewy flag should be true. I found a concurrency value of 10 to work well on my cluster but it is okay to play it safe and decrease that number or remove it altogether if your cluster is operating close to CPU capacity.

[hardillb]

@abbottmg Sorry I never got round to testing your PR.

Just checking I understand what your PR actually does. It runs the following command after the upgrade

bin/tootctl search deploy --concurrency X --reset-chewy

Where X is the value of mastodon.deploySearch.concurreny

So if I ran the current version of the helm chart (without this applied) I could use kubectl exec to run the same command in say the web container to get the same effect?

[abbottmg]

Yes, you should be able to manually run that command in any container running the webserver or sidekiq. Spinning up a dedicated container theoretically gives you the dual benefits of not blocking your main service in that container and scheduling that work on a node that has the resources free.