correct config.schema.indexName reference

[missinglink]

The indexName configuration is parented by schema, not by api.

ref: https://github.com/pelias/config/blob/4a52a15a85767407591deaabd78b4e87f09f74f7/config/defaults.json#L73
related: pelias/schema#507 (comment)

[missinglink]

Hmm actually this is wrong too
https://github.com/pelias/api/blob/master/schema.js#L22

@orangejulius sanity check plz, am I doing the right thing?

[missinglink]

api.indexName is referenced all over this repo but it's not in the default Pelias config, I'm much confused

[missinglink]

Oh I'm blind, it is duplicated in the config:
https://github.com/pelias/config/blob/4a52a15a85767407591deaabd78b4e87f09f74f7/config/defaults.json#L39

Do we need both?

[missinglink]

Oh wow, this goes back to 2016, now I'm afraid to change anything:
pelias/config@2c2284d

[missinglink]

I would advocate removing api.indexName.

The reason is that when you create an index you can change config.schema.indexName to whatever you like, but then pelias/api requires additionally setting config.api.indexName or it will fail to find that index, this seems unnecessarily confusing.

Is there a valid use-case where someone might want config.schema.indexName & config.api.indexName to differ?

[missinglink]

audit of our repos (we use a mix, and in some cases default to schema.indexName when api.indexName is unset):

https://github.com/search?q=org%3Apelias%20indexName&type=code

[missinglink]

ref: pelias/schema#507 (comment)

[orangejulius]

So, we originally created the distinction between the two indexName config options due to some one-off issue we had at Mapzen, something about the index names not matching up with what we expected.

But in general, I think it's potentially useful to some people to have both.

The way I always imagined it works is for someone who only has a single, long lived Elasticsearch cluster to be able to switch the API between multiple indices, and also create new indices and run builds while keeping an old one around for production traffic. Something like the style of a blue-green deployment.

The importers also use schema.indexName for this reason, so for example here's a scenario happening on a single Elasticsearch cluster:

• both schema and api point to pelias index
• config.schema.indexName changed to pelias-new
• new index is created by schema and importers are run
• once validated, config.schema.indexName is changed to pelias-new and the API is restarted, moving over query traffic

[missinglink]

OK, fair enough, I'm going to close this as a wontfix since having both is the expected behaviour.

[missinglink]

For anyone who find this issue in the future, a blue-green deployment can be achieved more simply using Elasticsearch Aliases with zero-downtime.

[orangejulius]

Ah, I remember the issue we had at Mapzen now: normally, we loaded builds in to Elasticsearch with an index name of the format pelias-$date, and then had pelias be an index alias to whichever build we wanted to be live. When we were loading a new build there would be pelias-$oldDate and pelias-$newDate in various levels of readiness on the same Elasticsearch cluster.

But then at some point something was messed up in our very convoluted and painful infrastructure setup, and we loaded an index into the cluster directly as pelias. That means we couldn't use an alias because there was an actual index there. We were stuck without a way to change which index the API used. Hence this config option.

I think having the configurability here in the API is still good, many people might prefer making changes to Pelias config instead of using Elasticsearch index aliases (one could imagine an infrastructure setup with read-only access to the Elasticsearch cluster for safety, but easy ways to change pelias.json without downtime). Plus it allows anyone to get out of the situation that we once faced at Mapzen.