Add a setting to disable stack installed templates #62835
Comments
|
Pinging @elastic/es-core-features (:Core/Features/Features) |
elasticmachine
added
the
Team:Data Management
|
Should we be installing these templates by default? This feels like a breaking change, where users that were previously using Elasticsearch in a legitimate manner by having indices named |
|
I've seen this occur already with a As opposed to a node-level setting, can something first prompt that a collision will occur and/or force a positive confirmation to proceed? Otherwise, it puts the onus on users to read through the release/upgrade notes, notice the potential collision, and make the setting change (++ dynamic). Failing that, the change is made and their own index templates will silently fail to apply. |
This change allows the setting for disabling the automatically installed stack templates (the `logs-*-*`, `metrics-*-*`, and `synthetics-*-*` templates) to be changed dynamically. As a byproduct, it also moves thes `IndexTemplateRegistry` to use an `initialize()` method so that constructors are not tempted to use a `this` reference in the constructor (see elastic#37861 for more information about why to avoid that). Resolves elastic#62835
|
This is awkward for writing deprecation logs to a data stream, since that functionality expects the |
|
@pugnascotia we currently already have the setting (#63764 just makes it dynamic), so we cannot remove it, I would suggest maybe that the deprecation log data stream install its own template (with a more narrow index pattern and higher priority) so that it's independent of the stack templates |
* Make stack.templates.enabled a dynamic setting This change allows the setting for disabling the automatically installed stack templates (the `logs-*-*`, `metrics-*-*`, and `synthetics-*-*` templates) to be changed dynamically. As a byproduct, it also moves thes `IndexTemplateRegistry` to use an `initialize()` method so that constructors are not tempted to use a `this` reference in the constructor (see #37861 for more information about why to avoid that). Resolves #62835
* Make stack.templates.enabled a dynamic setting This change allows the setting for disabling the automatically installed stack templates (the `logs-*-*`, `metrics-*-*`, and `synthetics-*-*` templates) to be changed dynamically. As a byproduct, it also moves thes `IndexTemplateRegistry` to use an `initialize()` method so that constructors are not tempted to use a `this` reference in the constructor (see elastic#37861 for more information about why to avoid that). Resolves elastic#62835
* Make stack.templates.enabled a dynamic setting This change allows the setting for disabling the automatically installed stack templates (the `logs-*-*`, `metrics-*-*`, and `synthetics-*-*` templates) to be changed dynamically. As a byproduct, it also moves thes `IndexTemplateRegistry` to use an `initialize()` method so that constructors are not tempted to use a `this` reference in the constructor (see #37861 for more information about why to avoid that). Resolves #62835
From #57629 onward we have started installing
logs,metrics, andsyntheticstemplates that match thelogs-*-*,metrics-*-*, andsynthetics-*-*index patterns.An issue arises when a user upgrades their cluster to a version that includes these templates while also using an index pattern that would coincide with these (such as a user having daily indices named
logs-data-things-2020-09-23for example).In order to mitigate these issues, we should add a node level setting that disables putting these templates in place automatically. The setting should also be dynamic (so as not to require restarting all the nodes if a user needs to get rid of the templates), and we should also better document the stack plugin, the built in templates, and potential issues that may arrive when a user upgrades.
The text was updated successfully, but these errors were encountered: