Elasticsearch: Consistent naming for the new index templates

[jakelandis]

Index templates are getting a big update in an upcoming release [1]. We should decide on how best to distinguish the old templates vs. the new templates.

Some references use v1 vs v2 index templates. Some references use legacy vs. 8.0.0 templates. However both of naming conventions may have issues.

v1 and v2 is sub-versioning within the Elasticsearch version and could be the cause of confusion. Further v2 sounds an evolution of v1 templates, while they serve some of same the purposes they are not really an evolution (i.e. automatic upgrade to v2 is a difficult problem)
. Also, there are plans to introduce this prior to 8.0.0 which could also cause confusion.

One suggestion is legacy vs. composable

The purpose of this issue to get consensus on the name used to differentiate these two templates as well as serve as a meta issue to ensure any documentation [1] or references reflect the agreed upon name.

[1]
https://www.elastic.co/guide/en/elasticsearch/reference/7.x/indices-templates.html

[elasticmachine]

Pinging @elastic/es-core-features (:Core/Features/Indices APIs)

[elasticmachine]

Pinging @elastic/es-ui (:ES-UI)

[jasontedor]

Thanks for opening this issue @jakelandis. The terms "legacy" and "composable" templates were only my suggestions to start the conversation, I'm not married to them and would certainly be open to other ideas that people have here. The important thing is to move away from the v1 and v2 naming.

[dakrone]

+1 on legacy and composable, I like those terms. And they're much better than V1 and v2.

[jasontedor]

@jakelandis How do you propose we move forward toward a decision here?

[jakelandis]

I too am +1 on legacy and composable.

@cjcenizal - does this work in the UI ? (and are you +1 ?)

@matt-davis-elastic - thoughts ?

[cjcenizal]

Thanks for the ping @jakelandis. Yes, composable and legacy work well from my perspective. I think "legacy" perfectly describes how we would like people to perceive v1 index templates. I think "composable" is a good way to describe the key advantage of v2 over v1. Here's a mockup that shows how we might communicate these two terms in the UI. @elastic/es-ui Please chime in with your 2 cents, too.

[matt-davis-elastic]

@cjcenizal Thanks for the screenshot. I am also +1 to these names. I have been using them since we last talked and it hasn't been surprising to anyone I have been talking to.

[jakelandis]

thanks @cjcenizal and @matt-davis-elastic I think that is enough consensus towards legacy and composable.

If anyone has strong objections, please re-open.

[danhermann]

Should the endpoints for composable templates be renamed from _index_template to _composable_template to match the new name?

[cjcenizal]

@danhermann I'm glad you suggested this. I think we should consider the long-term vision, which is for the removal of the _template API. In this world, does _composable_template make sense? I don't think so. To me, the concept we want to communicate is "a thing that applies customizable presets to new indices". I think composability is a secondary characteristic of the new index templates, and the name "composable template" is only helpful as long as we have "non-composable templates" to compare them to. So as much as I like the way "_composable_templates" reflects our terminology, I don't think it's the right choice for the long term.

I'm also really interested in hearing what @matt-davis-elastic, @jethr0null, and @debadair think about this.

[dakrone]

I'm going to re-open this, even though we have consensus, as a TODO for actually making the change (the majority of which is going to be in our documentation)